Tegra K1 - bluetooth issue

Robotics & Edge Computing Jetson & Embedded Systems Jetson TK1
1

We are trying to bringup bluetooth chip in Jetson TK1 and we are facing issues in file transfer. Here is the setup:

  1. WL1835MOD EVM board connected to SD-connector in Jetson TK1.

  2. Bleutooth UART lines are wired to UART2 TX, RX, CTS and RTS lines in the Jetson TK1 GPIO header.

  3. Booted the Jetson board and broughtup the bluetooth using the following command:
    hciattach -t 10 -s 115200 /dev/ttyTHS1 texas 3000000 flow; hciconfig hci0 up piscan

I am able to scan the nearby devices and see their MAC addresses. But when I am trying to send files over bluetooth to nearby Linux development PC (through Ubuntu GUI app), the Linux kernel hangs without any warning or crash messages.

Have anybody broughtup any bluetooth device in Tegra K1 and able to send/recevice files successfully?

NOTE:

  1. I have tried wiring up the same Bleutooth EVM to iMX6 processor and able to send/receive files over bluetooth without any issues. (Which means Bluetooth firmware is not an issue).

  2. I am using R21.4 Jetson release package (kernel version - 3.10.40). [In iMX6, 3.10.17 kernel version is used).

Thanks,
Jai

2

Do you have serial console running, and does this lock as well? I suspect that even if it locks you may be able to use the magic-sysrq key combinations. This probably has more than you are interested in, but is described here:
https://en.wikipedia.org/wiki/Magic_SysRq_key

To validate that magic-sysrq is enabled, look for a “1” from this:

cat /proc/sys/kernel/sysrq

The basic gist is that some parts of the kernel are usually still working even if user space is completely non-responsive. Using a keyboard directly connected to JTK1 (monitor via serial console, but use magic-sysrq via the Jetson’s keyboard), you could (if no other clues occur in log files or dmesg) take control of the keyboard (alt-sysrq-r), sync the disk (alt-sysrq-s), remount the disk read-only (alt-sysrq-r), completely unmount the disk (alt-sysrq-u), and then purposely induce a kernel panic (which will give a stack dump on the serial console…thus the serial console needs to be logging as you do this).

Obviously it is best to see if logs show anything before you go to that extent, but a less invasive approach which does nothing but remount read-only, umount, and then reboot (alt-sysrq- ‘r’, ‘u’, ‘b’) would ensure as much as possible of logs get flushed before boot. If serial console works without direct JTK1 access over keyboard/monitor, you can just debug directly and not even worry about forcing a kernel panic.

If you want to get into kernel debugging to any significant level you might pick up one of the Lauterbach JTAG debuggers. See:
http://www.electronique-mag.com/article10398.html
http://www.lauterbach.com/frames.html?pro/pro_tegrak1.php?chip=TEGRAK1
http://elinux.org/Jetson/JTAG