Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

Carles Cufi
 

Hi Frank,

 

Right, since this seems to be more about BlueZ and Qt than about Zephyr or nRF, because nRF chipsets do not come with a public address registered and burned into the chip, I have copied a couple of people familiar with BlueZ to see if they can help you.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of frv
Sent: 12 November 2018 12:14
To: devel@...
Subject: Re: [Zephyr-devel] Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832

 

[Edited Message Follows]

Hi Carles,

Humm... not quite, I have recently created a QT bug report (See : https://bugreports.qt.io/browse/QTBUG-71727)  although I think different parties are to blame, I'm still not sure who is doing really wrong, or miss interprets the data.

Thus to summarize again:
If no public address is set for the Nordic BT controller, the HCI adapter has by default address 00:00:00:00:00:00.

When Qt creates a QLowEnergyController object it uses the BT random address to find the HCI adapter (hciForAddress member function in the HciManager class), but as the random address is different from the default public address it is not able to create a QT BT socket, and thus all BLE actions will fail (E.g. advertising).

As QT uses the Bluez DBus function for retrieving the address info you could say it is the Bluez stack to blame, as the address is referring to the HCI adapter is the random address and not the public device address (00:00:00:00:00:00) (See attach pic of QDbusViewer).

Thus only after setting the public address different from the zero address (by means of the hcitool cmd) , Qt is able to create a correct LowEnergyController object for starting to advertise. But also in this case you could wonder why is in the DBus topology ("Property: AddressType") the public set address still typed as "random". 

I'm wondering how Qt will reply to the issue. Honestly I love to work with QT as a C++ developer.

Also the Zephyr HCI_UART running on the Nordic HW offers a different solution than using the plain C solution (serialize concept when separating connectivity board from application board) offered by Nordic or the C++ solution based on the Nordic PC BLE driver. Altough the latter also gives a nice solution for integrating BT in our products. 

Best regards,
Frank

Join devel@lists.zephyrproject.org to automatically receive all group messages.