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

    Thanks for the link to the guide. I was able to get the HCI UART sample working as explained in it. I was under the impression that I had to connect via the UART pins (exposed via GPIO 5, 6, 7, 8). I could only bring up the interface with the ttyACM0 interface created via the USB CDC interface. I read somewhere on the zephyr wiki page that the ttyACM0 interface is bridged to the nRF52's UART interface.

    I want to be able to run the board with battery. I tried to attach with the UART interface (through an FTDI UART converter with proper flow control pins connected) and I was able to set the BD address with the static-addr command on btmgmt but when auto-power command seems to fail. Only if I use the ttyACM0 interface was I able to power on with auto-power command.

    I am wondering if the bridging somehow affects the usage of plain UART pins. Is there a way to un-bridge this via software or jumper pins? Is it possible to talk to the nRF52 through the UART interface directly?

    Thanks.

Reply
  • 0 in reply to Håkon Alseth

    Thanks for the link to the guide. I was able to get the HCI UART sample working as explained in it. I was under the impression that I had to connect via the UART pins (exposed via GPIO 5, 6, 7, 8). I could only bring up the interface with the ttyACM0 interface created via the USB CDC interface. I read somewhere on the zephyr wiki page that the ttyACM0 interface is bridged to the nRF52's UART interface.

    I want to be able to run the board with battery. I tried to attach with the UART interface (through an FTDI UART converter with proper flow control pins connected) and I was able to set the BD address with the static-addr command on btmgmt but when auto-power command seems to fail. Only if I use the ttyACM0 interface was I able to power on with auto-power command.

    I am wondering if the bridging somehow affects the usage of plain UART pins. Is there a way to un-bridge this via software or jumper pins? Is it possible to talk to the nRF52 through the UART interface directly?

    Thanks.

Children
No Data
Related

core_v2_widget.Hide()