This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zephyr hci_uart on nRF52840 with FT232R

Hello,

I've been testing HCI_UART from Zephyr RTOS on nRF52840DK and own device which has nRF52840 + FT232R as USB-UART converter. Regarding the own device it's a circuit long tested working with other firmware and never had issues with how UART bahaves. Flow control is connected, normally everything is golden, even Nordic DFU works and flow control is a necessity for it.

My setup is the following:

  • Ubuntu 18.04, kernel 5.3.0-42
  • Bluez tested both 5.48 and 5.45
  • My default laptop Bluetooth device turned off by sudo hciconfig hci0 down just in case, to not interfere

When flashing Zephyr HCI_UART onto the nRF52840DK im attaching it by btattach -B /dev/ttyUSB1 -S 1000000 -P h4 later use btmon and I'm able to scan for BLE devices which is my first test if a HCI device is operating properly. On the other hand when flashing the same FW (after remapping the pins to my board, that is: tx-pin = <6>; rx-pin = <8>; rts-pin = <26>; cts-pin = <4>;) I start to see a strange error which I haven't been able to debug yet. After attaching my device my dmesg output is flooded by hci1: Frame reassembly failed (-84) and btmon output shows:

= New Index: 00:00:00:00:00:00 (Primary,UART,hci1) [hci1] 171.230779
= Open Index: 00:00:00:00:00:00 [hci1] 171.230791
< HCI Command: Reset (0x03|0x0003) plen 0 #1 [hci1] 171.232583
= Close Index: 00:00:00:00:00:00 [hci1] 181.394212

So it doesn't even reset.

Same happens when I don't set -P h4 and just use -R flag. All the resources I've found so far were related to rPi where people have encountered this issue but didn't find anything particularly useful. On devzone I've found https://devzone.nordicsemi.com/f/nordic-q-a/19295/zephyr-hci-uart-on-nrf52dk---hci-interface-bring-up-fails and https://devzone.nordicsemi.com/f/nordic-q-a/25936/zephyr-hci-uart-on-pca10040-with-linux-controller which being bit different show some resemblance to my experiences. Unfortunately I've haven't found my answer in these threads as well.

I've tried lowering the baud rates suspecting that FT232R has issues or even UART lines start doing funny stuff but with exactly the same results. Debugging with usbmon + wireshark showed me that there was some exchanges going back and forth but given that HCI protocol is quite new to me I didn't yet debug it's contents, just wanted to see if both sides exchange some data - which they are. Also occasionally btmon has thrown some errors about parsing incoming events which would indicate that there is traffic but it's wrong.

Afterwards my plan was to try to replicate similar behavior on the nRF52840 DK but this also failed. I could get different problems but not this one.

So after few hours of back and forth with trying everything I started suspecting that FTDI or it's driver might be doing some shenanigans. For now I haven't found any indication that Zephyr hci_uart could work while passing through an FTDI chip. Also https://www.ftdichip.com/Support/FAQs.htm#HwGen3 states that "Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis." which doesn't say much to me at the moment but sound suspicious.

This is the last difference I can see which could result in problems with parsing on Linux side, namely that nRF DK mounts as /dev/ttyACMx and my device as /dev/ttyUSBx. This might or might not be the cause which is hard to say at this moment, especially given that Larid BT860 module documents HCI working behind a FTDI chip but probably the implementation of the HCI stack is different in some way which takes FTDI on the way into consideration.

Did anyone here experience such issue or has any hints on what I could check?

  • Hello,

    Yes, what you wrote sums everything up. I had to switch to other projects for the time being but will come back to this as it's hard to understand for me what could be wrong. Tried on few computers and always the same results.

    I've also tried reducint both DFU firmware and btattach baud rates to 115200 or even lower but it always failed similarly so I ruled baud rate or some RX/TX lines issue. Once I'll find a CDC compatible USB-UART adapter I'll try removing FTDI and routing the UART lines to a different converter. Expect that this will work because maybe it's about some magical, vendor specific FTDI protocol... not sure but also why not. Though over years of using never had any issues with FTDI converters.

Related