• State Verified Answer
  • Replies 13 replies
  • Subscribers 63 subscribers
  • Views 11782 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

    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.

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

Children
No Data
Related