• State Verified Answer
  • Replies 13 replies
  • Subscribers 64 subscribers
  • Views 11868 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.

Parents
  • 0

    Hi,

    Did you compile hci_uart from master, or did you check out a given version?

    It may be that your bluez installation is a bit old. Have you tried following the guide by Carles?

    Note, if your kernel version is older (f.ex. 4.4.x), you may have to configure bluez with --enable-experimental for bluez to compile <bluezsrc>/tools/btattach

    Be sure to use btmon for monitoring and logging to see if the communication is up and running properly. This command should be called prior to btattach.

    Cheers, Håkon

  • 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!

Reply
  • 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!

Children
No Data
Related