Priority: P3: Somewhat important
Resolution: Out of scope
Affects Version/s: 5.11.2
Fix Version/s: None
Component/s: Connectivity: Bluetooth
I'm recently exploring the possibilities of using the Nordic nRF52 DK running Zephyr HCI_UART as BLE controller.
To have a quick BLE peripheral applic up and running I built the QT examples heartrate-server on my Ubuntu 18 Linux system.
As I'm using the Nordic HW platform the public address initialy is set to 00:00:00:00:00:00 after powering up.
After some debug work I noticed that the QLowEnergyController object created as peripheral uses the BT random address instead of the BT public address which is the zero-address. By doing so the HciManager and the hciForAddress function fails to create a BT socket as the HCI adapter/controller can not be found based on the random address.
In my case the BT random address is always after startup CB:49:DD:88:61:62, as the public address is still 00:00:00:00:00:00. Thus in the function call hciForAddress there is no match to find the right HCI adapter. BTW in my setup there is only one BT HCI adapter present, the internal one is disabled.
So it seems if the BlueZ stack finds a ZERO address for its Adapter1 it uses rather the random address.
This can be solved by setting the public BD address by calling the hci cmd 0x3f 0x006 "BD-ADDR" (Zephyr specific). In this case the QLowerPowerController object will correctly find the Hci adapter and create the bluetooth socket, and advertising can be done succesfully.
However when calling with QDbusViewer and quering the org.bluez I see that it now reports as random address the address that was set by the command hci cmd 0x3f 0x006 BD_ADDR.
So I'm wondering how is making the bug or is this behaviour normal?
So either I can set a public address after powering up the Nordic HW before calling the heartrate-server applic or I can adapt the QT code that should allow zero-address for finding the HCI controller/adapter. Of course the latter is more or less not acceptable.
Honestly I love the way Qt implements the Bluez stack and makes it much easier to address /implement BLE functionality.
BTW I have also reported the issue on Zephyr and Nordic Dev Zone,
https://devzone.nordicsemi.com/f/nordic-q-a/22194/read-or-change-nrf51-mac-address-on-zephyr (See my comments at the end by Frank)