Example Projects/Generated Code - Bluetooth Mac Address OUI validity

[HRadt.1]

All Examples for the STM32WB have the following code in their app_ble.c:

const uint8_t* BleGetBdAddress( void ) {
 ...
 udn = LL_FLASH_GetUDN();
 if(udn != 0xFFFFFFFF) {
 company_id = LL_FLASH_GetSTCompanyID();
 device_id = LL_FLASH_GetDeviceID();
 
 bd_addr_udn[0] = (uint8_t)(udn & 0x000000FF);
 bd_addr_udn[1] = (uint8_t)( (udn & 0x0000FF00) >> 8 );
 bd_addr_udn[2] = (uint8_t)( (udn & 0x00FF0000) >> 16 );
 bd_addr_udn[3] = (uint8_t)device_id;
 bd_addr_udn[4] = (uint8_t)(company_id & 0x000000FF);;
 bd_addr_udn[5] = (uint8_t)( (company_id & 0x0000FF00) >> 8 );
 
 ...
}

Also Application Note AN5289 has the same listing.

Comments and descriptions lets me believe this yields a valid public bluetooth address.

The address created is "80:E1:26:XX:XX:XX". The first part is the OUI which should belong to ST Microelectronics. But in fact 80:E1:26 is not assigned. STMs OUI is 00:80:E1.

So I have to assume that ST does not supply a valid MAC address for the STM32WB devices? In that case this should be mentioned somewhere clearly!

[DEdwi.1]

Your analysis seems reasonable that the example was attempting to use a public Bluetooth address and that your analysis points at ST not providing a pubic address. However it has always been challenging to allow usage of IC manufacturer's public address space for customers for flash parts.

I would suggest that you switch the address to a random static address (private) and move forward with the project. However the examples are better off using a random static address and avoiding this type of confusion. After you have generated the random static address, you will have to store it in persistent storage so it survives resets.

Ideally this should be in the ST API but if its missing it should be requested.

I hope this helps.

[Piranha]

That code is invalid as it's misusing the company ID (OUI).

> The 64-bit UID64 may be used by firmware to derive BLE 48-bit device address EUI-48 or 802.15.4 64-bit device address EUI-64.

That UID64 could be correct EUI-64, but for that to be the case ST has to strictly define the byte and (32-bit) word order. And for EUI-48 they have to define the same plus which bytes should be used. Until that is defined, the global uniqueness cannot be guaranteed.

[LBotl.1]

Hi Piranha, All,

can the user overwrite UID64?