BLE address no longer matches FICR->DEVICEADDR in NCS v3.x

[Haris Iqbal]

Hi,

I recently migrated a project from NCS v2.x to NCS v3.x and noticed that the method I previously used to generate a device-unique identifier no longer works the same way.

On NCS v2.x, I was using:

fill_bytes_from_int32_le_with_start_index(NRF_FICR->DEVICEADDR[0], c, 0);
fill_bytes_from_int32_le_with_start_index(NRF_FICR->DEVICEADDR[1], c, 4);

FICR->DEVICEADDR matched the device’s BLE MAC address, so I could derive a predictable unique ID based on the BLE public address.

However, after moving to NCS v3.x, FICR->DEVICEADDR is no longer available.
Following Nordic’s recommendation, I switched to:

fill_bytes_from_int32_le_with_start_index(NRF_FICR->INFO.DEVICEID[0], c, 0);
fill_bytes_from_int32_le_with_start_index(NRF_FICR->INFO.DEVICEID[1], c, 4);

This returns a totally different ID, which does not match the BLE MAC address anymore.

 My questions:

1. Why was FICR->DEVICEADDR removed in NCS v3.x?
   Previously, it corresponded to the BLE public address burned into FICR.

2. Is the BLE controller in NCS v3.x no longer using the FICR DEVICEADDR as the identity address?

3. What is the correct way to obtain the BLE public (identity) address in NCS v3.x?
   Should we use bt_id_get() exclusively?

4. If I want a stable and predictable device identifier that matches the BLE MAC (as before), is there a supported method to configure the controller to use the FICR address?

5. Is there an official statement or migration note explaining this change?

Additional info:

• Board: nRF5340dk

• NCS version: 3.0.2

• Using Zephyr Bluetooth Controller (not SoftDevice)

I used to put the DEVICEADDR (8 Octets) into BLE characteristic to generate a UUID unique to that device, it should match the 6 Octets in the BLE MAC address.

Thanks in advance for the clarification.

[Einar Thorsrud]

Hi,

Why was FICR->DEVICEADDR removed in NCS v3.x?
Previously, it corresponded to the BLE public address burned into FICR.

It has not been removed. This is part of the SoC itself, and the macros you use for accessing it also exists. Could it be that you have made some other changes while migrating and is now trying to read this from the application core? Note that the DEVICEADDR register only exist in the FIRC for the network core and can only be accessed like this from the network core.

Is the BLE controller in NCS v3.x no longer using the FICR DEVICEADDR as the identity address?

It can still be used as the identity address.

What is the correct way to obtain the BLE public (identity) address in NCS v3.x?
Should we use bt_id_get() exclusively?

Yes, that is more portable and generic. This also works also if another identity address is used (say another random static address or a public address).

Is there an official statement or migration note explaining this change?

I do not think so, and the DEVICEADDR from FIRC can still be used.