RE: nrf54l15-dk set ble Identity

Edvin — Tue, 15 Apr 2025 13:05:55 GMT

I thought you could use bt_id_get(), but it turns out it shows the wrong address. I guess it only uses this if you create an ID in the first place, so then you can use it. In case you don't actively create an ID, it is possible to deduce the address based on the device's FICR registers. There is a FICR register called DEVICEADDR[n], n=0..1.

The ordering of these address bytes may be a bit confusing, but the DEVICEADDR[0] contains the least significant bits that makes up the last 4 bytes of the address. The two most significant bytes comes from DEVICEADDR[1]. You can give this function a shot:

static void check_address(void)
{
    //void bt_id_get(bt_addr_le_t *addrs, size_t *count);
    bt_addr_le_t *my_addresses = NULL;
    size_t num_addresses;
    bt_id_get(my_addresses, &num_addresses);
    LOG_INF("num_addresses: %d", num_addresses);
    for (int i=0; i<num_addresses; i++)
    {
        LOG_INF("addr #: %02x:%02x:%02x:%02x:%02x:%02x", my_addresses[i].a.val[0],
                                                         my_addresses[i].a.val[1],
                                                         my_addresses[i].a.val[2],
                                                         my_addresses[i].a.val[3],
                                                         my_addresses[i].a.val[4],
                                                         my_addresses[i].a.val[5]);
    }

    LOG_INF("ficr address: %02x:%02x:%02x:%02x:%02x:%02x", (((NRF_FICR->DEVICEADDR[1] & 0x0000FF00)>>8) | 0b11000000),
                                                           ((NRF_FICR->DEVICEADDR[1] & 0x000000FF)>>0),
                                                           ((NRF_FICR->DEVICEADDR[0] & 0xFF000000)>>24),
                                                           ((NRF_FICR->DEVICEADDR[0] & 0x00FF0000)>>16),
                                                           ((NRF_FICR->DEVICEADDR[0] & 0x0000FF00)>>8),
                                                           ((NRF_FICR->DEVICEADDR[0] & 0x000000FF)>>0));

}

As you can see, it prints both the addresses fetched from bt_id_get() and the FICR values. I did some bit-manipulation to print it in a more readable way. Note that the first byte in the address, I added " | 0b11000000", because the two most significant bits in the most significant bytes must be 1 when you are using a random static address (the default address type), according to the Bluetooth specification. The softdevice does this.

I am not sure exactly why you need the address, but you can see from most of our samples, the actual address is also printed in the log during bootup:

But that information is not reachable in your main.c file. But the above function should let you see the address from FICR.

Best regards,

Edvin

RE: nrf54l15-dk set ble Identity

dede — Tue, 15 Apr 2025 01:56:18 GMT

Hi,Edvin,

Thank you for your reply.

[quote userid="26071" url="~/f/nordic-q-a/120650/nrf54l15-dk-set-ble-identity/531545"]But is what you actually want to do is to figure out what address you have, without generating a new one?[/quote]

Yes. You are right. In the absence of a connection, which API should I use to get the BLE address of the device itself.

Thanks.

RE: nrf54l15-dk set ble Identity

Edvin — Fri, 11 Apr 2025 13:45:37 GMT

Hello,

I am a bit confused. Do you intentionally don't want to use the BLE address that is pre-programmed on the device?

But the short answer is no, the devices will not generate the same address. I have not seen the implementation, but I believe this generated address will be based on the pre-programmed address (not recognizable, but it is possible for a bonded device to resolve the original address from the new ones).

But is what you actually want to do is to figure out what address you have, without generating a new one?

Best regards,

Edvin