Using nRF5340-PDK with HCI USB sample: hci device not found on Ubuntu

[Martin Striegel]

Hi,

I am aware, that I the PDK is deprecated and I plan to use a nRF5340-DK in the near future.

However, I would like to make use of the PDK I have sitting around and thus tried to convert it to a BT 5-enabled USB Dongle using the HCI USB sample.

I built the sample `hci_usb` from Zephyr (version 2.5.0) using  `west build -b nrf5340pdk_nrf5340_cpuappns --pristine`  which automatically included the `hci_rpmsg` as child image due to CONFIG_BT_RPMSG_NRF53 being set to 'y'. I flashed the combined image using `west flash --erase` and UART console output showed:

[17:14:08:809] *** Booting Zephyr OS version 2.4.99 ***␍␊

[17:14:08:812] Bluetooth over USB sample␍␊

Eager to try it out, I ran `hciconfig` on my Ubuntu 19.10 machine with BlueZ 5.50 and did not see an additional Bluetooth adapter. `lsusb` still shows the nRF53 as JLink device.

I'd like to narrow down the problem:

• did I do something wrong during the build or flashing process?
• is the nRF5340 PDK incompatible with this example? https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_nrf5340.html#building-and-programming-a-sample states, that most examples should work but have not been tested thoroughly with the nRF53
• is the problem caused by my Ubuntu?
• has anyone managed to run this example on a nRF53, be it the PDK or DK?

Any response is appreciated!

Martin

[Martin Striegel]

Update: I found and followed this blog post (https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos), which describes exactly what I am up to.

However, I do not understand the difference between `hci_uart`, `hci_usb` and `hci_usb_h4` samples. It seems the nRF53 supports USB, so should I prefer the latter samples over `hci_uart`?

Steps I did after having flashed the `hci_uart` sample (to follow your blog post):

sudo service bluetooth start

# my nRF53PDK shows up as. I tried all of those with btattach command
/dev/ttyACM1 - SEGGER_J-Link_000960113693
/dev/ttyACM3 - SEGGER_J-Link_000960113693
/dev/ttyACM4 - SEGGER_J-Link_000960113693

sudo btattach -B /dev/ttyACM1 -S 1000000 -P h4
Attaching Primary controller to /dev/ttyACM1
Switched line discipline from 0 to 15
Device index 1 attached

btmon shows:

= New Index: 00:00:00:00:00:00 (Primary,UART,hci1)                                                                 [hci1] 104.429211
= Open Index: 00:00:00:00:00:00                                                                                    [hci1] 104.429227
< HCI Command: Reset (0x03|0x0003) plen 0                                                                       #2 [hci1] 104.429237
= Close Index: 00:00:00:00:00:00        

I expect that the problem starts here, as I assume, that hci1 should not be closed immediately. Still, I continued:

sudo btmgmt --index 1 # index 0 is used by the internal BT controller of my laptop
[hci1]# auto-power
Waiting for index 1 to appear

I then use hciconfig and see, that there are indeed hci0 and hci1 (which is shown as DOWN). However, when I do `sudo hciconfig hci1 up`, it gives me a timeout and `btmon` shows:

@ RAW Open: hciconfig version 2.22                                                                               {0x0004} 355.759208
@ RAW Close: hciconfig                                                                                           {0x0004} 355.759503
@ RAW Open: hciconfig (privileged) version 2.22                                                                  {0x0004} 361.789043
= Open Index: 00:00:00:00:00:00                                                                                    [hci1] 361.789056
< HCI Command: Reset (0x03|0x0003) plen 0                                                                       #3 [hci1] 361.789100
= Close Index: 00:00:00:00:00:00                                                                                   [hci1] 371.871702
@ RAW Close: hciconfig                                                                                           {0x0004} 371.872091

I hope this additional is helpful. Thanks a lot!

Martin

[Sigurd]

Hi,

Martin Striegel said:

It seems the nRF53 supports USB, so should I prefer the latter samples over `hci_uart`?

You would need the nRF5340-DK to use the built-in USB. Due to this errata on the engineering version of the nRF5340, the nRF USB port is not mounted on the PDK. This errata is fixed on the production version of the nRF5340.

 

Martin Striegel said:

I found and followed this blog post

 Note that the blog post is 4-5 years old, so some information there might not be up-to-date.

AFAIK, both hcitool and hciconfig have been deprecated upstream.Try using bluetoothctl instead, here's a blog post with a few commands: https://hasanyavuz.ozderya.net/?p=423

[Martin Striegel]

Dear Sigurd,

thanks for your reply! According to the ArchLinux Wiki, hcitool and hciconfig are indeed deprecated (https://wiki.archlinux.org/index.php/Bluetooth#Deprecated_BlueZ_tools), while btattach and btmgmt are still up-to-date.

Thanks for posting the erratat. I understand that the `hci_usb` sample will not work with my PDK, but is there any chance to be able to use `hci_uart`? I am aware, that only one out of three UARTs is functional, but shouldn't this one be sufficient to run the sample?

[Sigurd]

Hi,

Yes, I would expect hci_uart to work on the nRF5340PDK. There is also an overlay for it, https://github.com/nrfconnect/sdk-zephyr/tree/master/samples/bluetooth/hci_uart/boards, nrf5340pdk_nrf5340_cpuapp.overlay. Try to build it for nrf5340pdk_nrf5340_cpuapp , the file merged_domains.hex will contain both the code for the application and network core.

merged_domains.hex 

[Martin Striegel]

Hi Sigurd,

Success! I flashed the .hex your provided and it works:

TODO: Build firmware myself and check, whether it works.

Steps to making things work for further reference:

Terminal 1: Launch `btmon`

Terminal 2: `sudo btattach -B /dev/ttyACM3 -S 1000000 -P h4`. Note how I am using ttyACM3 this time, using /dev/ttyACM1 earlier probably caused all of my headaches. Output of `btattach`:

Attaching Primary controller to /dev/ttyACM3
Switched line discipline from 0 to 15
Device index 1 attached

There is not much information on `btattach` on the Internet and the man page is not useful, either. It showed `Device index 1 attached` whether the subsequent steps worked or didn't work, so we can not rely on its output.

However, this time, `btmon` provided lots of output:

// snip

      Read Controller Information (0x0004) plen 280
        Status: Success (0x00)
        Address: 00:00:00:00:00:00 (OUI 00-00-00)
        Version: Reserved (0x0b)
        Manufacturer: Nordic Semiconductor ASA (89)
        Supported settings: 0x0001be1b
          Powered
          Connectable
          Discoverable
          Bondable
          Low Energy
          Advertising
          Secure Connections
          Debug Keys
          Privacy
          Static Address
          Unknown settings (0x00010000)
        Current settings: 0x00008a11
          Powered
          Bondable
          Low Energy
          Secure Connections
          Static Address
        Class: 0x000000
          Major class: Miscellaneous
          Minor class: 0x00
        Name: martin-laptop #2
        Short name:

In a third terminal, I did `sudo btmgmt -i 1` and then:

[hci1]# auto-power
Found controller with index 1

It refused to change device address via static-addr <address>, but that's fine. I then use `bluetoothctl` to work with the device, just as I would do with the internal BT adapter of my laptop. Next steps: Test, whether the nRF53PDK talks to my nRF52840-based Bluetooth peripheral.

Thank you for your support!

Martin

[Santhosh AJ]

Can you please share the Hex file got from Sigurd or you built by your self which is working with 5340dk