• State Verified Answer
  • Replies 13 replies
  • Subscribers 63 subscribers
  • Views 11819 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 119294
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

zephyr HCI UART on nRF52DK - HCI interface bring up fails

sundar

Hi,

I am not sure if this is the right place to open up a thread about a zephyr HCI firmware issue. Since Nordic also contributes to zephyr I'm putting up this question here.

I have compiled the hci_uart sample from zephyr and flashed zephyr.hex to my nRF52DK board via JLINK. I connected the UART pins (TX, RX, RTS and CTS) to an FTDI USB-UART converter plugged to a Raspberry Pi 3 running Linux (Raspbian) and tries to enumerate with hciattach.

Here's what I did:

#sudo hciattach -s 115200 ttyUSB0 any 115200 flow Device setup complete

#sudo hciconfig hci1 hci1: Type: BR/EDR Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 27:7 SCO MTU: 0:0 DOWN RX bytes:224 acl:0 sco:0 events:15 errors:0 TX bytes:76 acl:0 sco:0 commands:15 errors:0

#sudo hciconfig hci1 up Can't init device hci1: Cannot assign requested address (99)

What I tried so far:

  • Reset the nRF52DK before performing the HCI attach as well but it's not helping
  • All the pins - Ensured TX, RX, RTS and CTS are connected correctly
  • Tried assigning a BDADDR by
    passing an address to hciattach but
    doesn't help
  • Configured 115200 as the baud rate in the zephyr kernel configuration and by default flow control is enabled
  • Turning off/on the flow control from hciattach doesn't help either

I am not sure what's going wrong but there seems to be no communication happening between the nRF52DK and the Host (R-Pi3).

Any help would be appreciated.

  • 0 in reply to Håkon Alseth

    It appears as a /dev/ttyUSBx interface on Linux. The RTS from the nRF52DK is connected to the CTS pin in the FTDI module and vice versa for the board's CTS pin. It does not seem to be an issue with flow control because the other HCI commands and events are getting transferred. If the RTS/CTS pins are not connected the static-addr command would fail and BTMON wouldn't show the capabilities info upon init.

    Only the HCI reset command is not getting processed. Weird.

  • 0 in reply to Håkon Alseth

    Weird indeed. That said in your ttyUSBx log I see you have 2 controllers connected, maybe we could start by removing one of them. Also I'm not sure who's sending that Reset command, seems strange that btmgmt would do that at that point in time. The only option I can see right now is to sniff the GPIO pins with a logic analyzer to see whether the reset command is reaching the nRF52. Or you could also try to modify the code in hci_uart so that every time it receives a packet it blinks an LED or something similar.

  • 0 in reply to Håkon Alseth

    The Linux host has two controllers and I have brought down hci0 (the on-board interface) before the experiments. I don't have a logic analyser with me so I'd have to consider the LED blink option or the RTT method. I'm hoping to configure the RTT support and debug using the JLink debugger. I'll try and update.

  • 0

    I am also working though this problem: moving the UART connection from the Segger JLink-based VCP to PCA10040 header pins. A photo of my setup is at drive.google.com/open A photo of the UART GPIO pins: drive.google.com/open A photo of the SBxx to be cut: drive.google.com/open I have been working on the for a couple days and believe it too is related to HW flow control: RTS/CTS lines are at issue.

    As a related point, I have been successful in getting the HCI-H4 to work when I interconnect the Raspberry Pi with the PCA10040 via the Segger JLink VCP. see screenshot drive.google.com/open

  • 0 in reply to Håkon Alseth

    Well I finally figured it out. It was a problem with the Raspberry Pi in my case. I could make it work with the UART interface with an x86 laptop running Linux. I believe it has something to do with the FTDI UART driver on the Pi. It worked occasionally and crashing the kernel in a while. So it has nothing to do with the UART interface being bridged by the USB CDC ttyACMx interface. Thanks for the help and timely responses from the community!

Related