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

    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.

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

Children
No Data
Related