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?

Parents
  • Hello Einar,

    The project in terms of hardware was a evolution from nRF52832 based project so when nRF52840 came out we did not want to implement full USB stack and port currently existing firmware to support nRF52840 focusing on it's new BLE features. So while getting rid of FTDI is on the roadmap it wasn't really a priority.

    Crystal wise both are mounted in the design. Today I've tested on a different design which instead of FTDI has an STM controller which acts as intermediary for UART along other things and enumerates as CDC /dev/ttyACMx device using ST USB stack. It wasn't possible to replicate the FDTI problems but this also doesn't work though this time the frame was too short according to btmon.

    So maybe it's not related to the USB conversion after all but HCI_UART relying on one of GPIOs on DK for some reason? There was nothing in the overlay file which I've just added my UART pin definitions but the rest of DTS is quite extensive and a bit intimidating get into when starting with Zephyr

  • Hi,

    Have you made any progress? The HCI_UART sample does not rely on other GPIO pins. It is interesting that you see different behavior using a different USB-UART bridge, but I do not understand what is going on.

Reply Children
No Data
Related