WL1837MOD: Bluetooth fails after Linux upgrade

Hi Trond,

Which UART signals are you probing? Can you provide a screenshot of RX, TX, BT_EN, and RTS from the WiLink?

Thanks,
Jacob

Hi Jacob,

Please find attached the screenshot of the WiLink UART signals.

Thanks,

Trondlinux-5.4-timeout.rtf

Hi Jacob,

I have made some debugging in the source code for hciattach; and found that not a single byte is read out of /dev/ttymxc2.

I put a break in the first read call - it will never return.

It is in hciattach.c in the yellow line below:

int read_hci_event(int fd, unsigned char* buf, int size)
{
int remain, r;
int count = 0;

if (size <= 0)
return -1;

/* The first byte identifies the packet type. For HCI event packets, it
* should be 0x04, so we read until we get to the 0x04. */
while (1) {
r = read(fd, buf, 1);

Regards,

Trond

I made a pdf file as well:

linux-5.4-timeout.pdf

Hi Trond,

Thank you for the materials. It looks like your RTS line is working correctly and information is sent over RX and TX. However, BT_EN should start low and then assert high, triggering RTS to go low. Are you ever setting BT_EN high?

Thanks,
Jacob

Hi Jacob,

BT_EN start low when Linux is booting and as the last part of booting it will get high and stay high. This behavior is the same in both versions of Linux.

I have a strong feeling that the UART signaling is correct but that the data is getting lost in the Linux tty stack - what could it be that is different between version 4.9 that is working and in 5.4 that is not?

Regards,

Trond

Hi Trond,

It looks like BT_EN starts low, then asserts high, and there is communication between RX and TX. I agree that the UART signaling is likely not the issue. Can you provide the implementation of read_hci_event from Linux 4.9.67-fslc? Does it also use a character buffer with the read function?

Thanks,
Jacob 

Hi Jacob,

The implementation of read_hci_event is exactly the same running on both versions of Linux - it is same binary of the hciattach user application.

Regards,

Trond 

Hi Trond,

That is very strange. I’ll look into how we can debug tty.

Thanks,’

Jacob

Hi Trond,

Can you list the full command you use here? How do you set the device name to "texas"?

Trond Sandvik said:

# hciattach -p /dev/ttymxc2 texas

I would recommend comparing git branches in the Linux Freescale repo to see what changes were introduced to the tty driver.

The Bluetooth chip on the WL1837MOD communicates over UART. This seems like a Linux issue to me.

Thanks,
Jacob

Hi Jacob,

It is the full command and "texas" is a parameter known to the application; to configure the UART for a TI device.

I agree that this seems to be a Linux issue - I have posted this on NXP forum as well. 

TTY Linux driver is complicated topic. Are there any TI Linux experts listening to this forum?

Thanks,

Trond

Hi Trond,

Unfortunately, there are not any TI-Linux experts on this specific forum. You can try posting your Linux question on the "Processors" forum, but that thread likely won't receive a dedicated response unless the OS used is TI-specific.

I would recommend using the Freescale forum. Feel free to follow up here with any more WiLink Bluetooth questions.

Best regards,
Jacob

Hi Trond,

Can you try running hciattach by specificying a baud rate of 115200? If that does not help, can you try 3000000?

hciattach -p /dev/ttymxc2 texas 115200

If this does not solve the problem, can you try running these commands before hciattach (Note : # below represents the gpio number that is connected to the BT_EN pin and $ represents the tty port connected to HCI pins):

echo # > /sys/class/gpio/export

echo "out" > /sys/class/gpio/gpio#/direction

echo 0 > /sys/class/gpio/gpio#/value

echo 1 > /sys/class/gpio/gpio#/value

echo 0 > /sys/class/gpio/gpio#/value

echo 1 > /sys/class/gpio/gpio#/value

hciattach /dev/tty$ texas 3000000

Relevant threads:

> https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/683824/linux-wl1837mod-hciattach-initialization-timed-out-inspite-the-tiinit_11-8-32-bts-being-present-the-initialization-is-failing

> https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/866918/wl1837mod-wifi-and-bt-enable-cause-sporadic-hciattach-timeout 

> https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/704972/linux-dra745-wl1837mod-hciattach-initialization-timed-out 

Thanks,
Jacob

Hi Jacob,

I tried your suggestions above by toggling the BT_EN line and changing the baud rate - it did not do any difference.

Btw to change the baud rate I had to use the -s paramter for the hciattach command; as it is the initial speed we are talking about. 

# hciattach h
hciattach - HCI UART driver initialization utility
Usage:
hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty> <type | id> [speed] [flow|noflow] [sleep|nosleep] [bdaddr]
hciattach -l

Again - the initial UART communication looks fine - it is the first reading out the /dev/ttymxc2 that will give no data.

Trond

Hi Trond,

The issue could be in the device tree or in the Linux tty driver. Let's focus on the device tree. I'll follow up here with more information this week.

Thanks,
Jacob

Hi Trond,

I should mention that TI does not officially support the BlueZ stack, as we encourage customers to use our Bluetopia stack for Linux. 

However, if you can get more output from the hciattach command, that would be very insightful.  

I think the second best way to further debug is to ensure the device tree is not the issue. I'm attaching the device tree specification from devicetree.org. Perhaps chapter 4.2 on serial devices will be of help. 

 devicetree-specification-v0.3.pdf

I can try to answer any further questions you have on the WiLink device.

Thanks,
Jacob

Hi Jacob,

Thanks for the information.

I have a feeling that it is more likely a Linux kernel configuration issue. We are using UART3 and the device tree entry is like this:

&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3>;
fsl,uart-has-rtscts;
fsl,dte-mode;
assigned-clocks = <&clks IMX7D_UART3_ROOT_SRC>;
assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
status = "okay";
};

I just used gdb with a breakpoint just before the first write to /dev/ttymxc2 in "hciattach /dev/ttymxc2 texas" and compared the tty settings running different kernel version. They are exactly equal:

********* Linux 5.4.3:

# stty -F /dev/ttymxc2 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

********* Linux 4.967:

# stty -F /dev/ttymxc2 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

Trond

Hi Trond,

Was your Linux-5.4-fslc build provided by TI? Otherwise, I'm afraid I will not be of much help with kernel configuration.

If you have more WiLink or Bluetooth questions feel free to follow up.

Best regards,

Jacob

Hi Jabob,

I did some more observations enabling dynamic kernel logging form  the imx.c serial driver.

I can see that the driver is receiving far too much data after just writing 4 bytes - it is expected to receive 15 bytes, but will get 4096:

# cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
0: uart:IMX mmio:0x30860000 irq:47 tx:3986 rx:23 RTS|DTR|DSR|CD
2: uart:IMX mmio:0x30880000 irq:48 tx:0 rx:0 CTS|DSR

[ 159.065862] imx-uart 30880000.serial: RX: prepare for the DMA.
[ 159.072417] imx-uart 30880000.serial: TX: prepare to send 4 bytes by DMA.
[ 159.079392] imx-uart 30880000.serial: we finish the TX DMA.
[ 159.085007] imx-uart 30880000.serial: We get 1024 bytes.
[ 159.090375] imx-uart 30880000.serial: We get 1024 bytes.
[ 159.095712] imx-uart 30880000.serial: We get 1024 bytes.
[ 159.101039] imx-uart 30880000.serial: We get 1024 bytes.

# cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
0: uart:IMX mmio:0x30860000 irq:47 tx:4217 rx:28 RTS|DTR|DSR|CD
2: uart:IMX mmio:0x30880000 irq:48 tx:4 rx:4096 CTS|DTR|DSR

In the Linux 4.9.67 that is working I will get this:

# cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
0: uart:IMX mmio:0x30860000 irq:47 tx:4217 rx:28 RTS|DTR|DSR|CD
2: uart:IMX mmio:0x30880000 irq:48 tx:4 rx:4096 CTS|DTR|DSR

[ 613.935269] imx-uart 30880000.serial: RX: prepare for the DMA.
[ 613.941457] imx-uart 30880000.serial: TX: prepare to send 4 bytes by DMA.
[ 613.948339] imx-uart 30880000.serial: we finish the TX DMA.
[ 613.954271] imx-uart 30880000.serial: We get 15 bytes.

# cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
0: uart:IMX mmio:0x30860000 irq:45 tx:9029 rx:244 RTS|DTR|DSR|CD
2: uart:IMX mmio:0x30880000 irq:46 tx:4 rx:15 RTS|CTS|DTR|DSR|CD

Trond