This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1837MOD: Bluetooth fails after Linux upgrade

Part Number: WL1837MOD
Other Parts Discussed in Thread: WL1837,

We have developed a custom board using the WL1837; connecting the Bluetooth interface to an iMX7D  UART.

This is working perfectly fine on our released product using Linux-4.9.67-fslc.

We are now working on supporting WoWlan. For this we have upgraded the kernel to Linux-5.4.3-fslc.

The WiFi part is working well, but the Blutooth part is not. We are getting timeout using the hciattach application:

# hciattach -p /dev/ttymxc2 texas
Initialization timed out.

looking at the UART signals on a logic analyzer they are exactly the same for both versions of Linux.
Hence data that should be received over the tty interface in Linux is getting lost for Linux-5.4.3-fslc, but not for  Linux-4.9.67-fslc.

Can anyone give a hint for a solution for this - I am getting empty for what to look for here in the tty domain..

  • 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

  • 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"?

    # 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

  • Hi Jacob,

    I  just resolved this issue. It was the SDMA firmware used in the UART3 driver that needed to be upgraded.

    Trond