Configuration of Public Device Address

[OKloe.1]

Dear all,

I am currently evaluation the BlueNRG-LP for a new project. I am using the STEVAL-IDB011V1 board and BLE stack v3.1. I've started with the BLESensorDemo to implement our own service. My question is regarding the BLE address.

This is how it is defined in the BLE spec.:

Public Device Address

This is the standard, IEEE-assigned 48-bit universal LAN MAC address which must be obtained from the IEEE Registration Authority. It is divided into two fields:

IEEE-assigned company ID held in the 24 most-significant bits

Company-assigned device ID held in the 24 least significant bits

So, due to spec. the BLE address shall be unique. The company ID should be some ID which identifies it as an ST or BlueNRG device which is registered to IEEE. 

The device ID should identify a device among the company ID. So, it has to be set by ST and not the customer as the customer cannot know all the devices.

But apparently it is possible to configure the address in the BlueNRG-LP which makes it NOT UNIQUE.

/* Configure Public address */
  ret = aci_hal_write_config_data(CONFIG_DATA_PUBADDR_OFFSET, CONFIG_DATA_PUBADDR_LEN, bdaddr);
  if(ret != BLE_STATUS_SUCCESS){
    printf("Setting BD_ADDR failed: 0x%02x\r\n", ret);
    return ret;
  }

Maybe this is a missunderstanding. But, I know from other projects where other BLE SoC's are used that there is no configuration possible when using public addresses. The devices have a static and unique address.

What is the right configuration to get a unique address according to spec. ?

Best Regards

Oliver

[Sebastien DENOUAL]

Hi @OKloe.1​ ,

This is true public addresses are defined by IEE and are guaranteed unique. BlueNRG-LP like big majority of BLE chipset do not have a valid preassigned MAC address.

In case you want to use unique public addresses, you need to request (and pay) for a pool of addresses to IEEE. Then, you will have to manage this pool in production (flash each device with one of unique public addresses).

Now, depends of your specific needs, most of customers are using static random address. This static random address is generated (and stored in specific flash region) at the very first boot. This address can then be used by BLE stack during whole product life. Agree it can't be 100% guarantee unique.. but risk to get 2 similar random address in the same range is very very low... this is solution implemented by most of BLE device.

More details in PM0269 - BLE stack V3.X programming guidelines section 3.1.1 (page 44 to 46)

Regards,

Sebastien.

[OKloe.1]

Hi Sebastien,

thanks for the quick response.

You already mentioned the requirement which is important: "This address can then be used by BLE stack during whole product life"

So, the BLE address needs to stay the same during the product life. Even if the firmware uspdated with internal bootloader.

Can the static random address be stored in a flash region which is not affected by an update?

Best regards

Oliver

[Sebastien DENOUAL]

Hi @OKloe.1​ ,

Yes: This static random address is stored in NVM - On the field, during product life while doing OTA/FW update, this NVM section is not deleted - So MAC address is kept..

Only a "FULL mass erase" of the BlueNRG-LP chipset will erase this NVM section.

In case of a full mass-erase, no more valid MAC adress are found by BLE stack and so a new BLE random MAC address will be generated by BLE Stack and stored in NVM.

Regards,

Sebastien.

[OKloe.1]

Hi Sebastien,

that sounds good. But where is the section where the address is stored? Can it be configured?

We will most likely use our own bootloader and therefore this section needs to be avoided.

Regards

Oliver

[Sebastien DENOUAL]

Hi Olivier,

By default, linker files from BlueNRg-LP SDK examples placed this NVM section (4k) at end of the flash. On BlueNRG-LP : from 0x1007F000 to 0x10080000. Linker file are also taking care of this NVM section for placement of application and available flash size.

This default placement of NVM should be compatible with a custom bootloader implementation. (we are used to)

Regards,

Sebastien.

[OKloe.1]

Hi Sebastien,

thanks a lot. But that leads to my last question.

I already discovered that NVM is included in all example projects I looked at even if it's not used by the application.

So I guess it is mandatory for the stack?

Regards

Oliver

[Sebastien DENOUAL]

You are right @OKloe.1​ , I confirm this NVM section is used by BLE stack to store BLE KEYs, pairing/bonding table,....

Regards,

Sebastien.