nrf54l15-dk set ble Identity

[dede]

Hi,Team,

I am developing ble using nrf54l15-dk.

My goal is to get the ble identity address of the device, but I don't know how to read it.

I found " bt_addr_le_create_static(&addr) ", which creates a Bluetooth LE random static address. So I know the ble identity address.

I have a problem with bt_addr_le_create_static(&addr). Even though random mac addresses can be generated, But if thousands of devices are powered on and this function (bt_addr_le_create_static(&addr) is used to generate ble identity addresses, will the thousands of devices generate the same ble identity addresses?

 My ncs version is v2.8.0.

Thanks.

[Edvin]

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

[dede]

Hi,Edvin,

Thank you for your reply.

 

Edvin said:

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

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.

[Edvin]

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