2023-01-04 12:53 PM
Hello,
I recently purchased STM's BLE nucleo expansion board, which works without issue.
I am reviewing the software to develop my understanding and had a question regarding the MAC address.
They are typically a unique address to the specific chip that is used and that every manufactured piece had a different MAC address. However, for the sample code (SensorDemoBLE), I never had to put in the IDB05A2's BLE MAC address. It knew, which means that every IDB05A2 must have the same MAC address.
Judging by this, is this assumption about the MAC address being unique wrong? In other words, if I ordered another Bluetooth BlueNRG-M0A chip, would it also have the same MAC address as the sample code?
Solved! Go to Solution.
2023-01-05 12:44 AM
Hi @KMew ,
BlueNRG-M0A module embeds a BlueNRG-MS chipset and so this chipset documentation is also valid in this case.
About MAC address, I would advise to check PM0237 : BlueNRG-MS stacks programming guidelines section 3.1.1. It describes the different type of BLE MAC address and how to use them.
To make it short, this BlueNRG-MS ( and so the associated BleuNRG-M0x module) don't have a preassigned MAC address. As you mentioned, each device is having a unique id .. but this is not a preassigned MAC address.
So, you are right : BLE MAC address should be handle at application level.
There is different type of MAC address : PUBLIC, PRIVATE or RANDOM. Except is you have specific requirements, usually selecting a random mac address is preferred solution.
In this case, at very first boot, device will generate (and store) a random MAC address that will remain valid for the whole life of product.
Hope it helps,
Regards,
Sebastien.
2023-01-05 12:44 AM
Hi @KMew ,
BlueNRG-M0A module embeds a BlueNRG-MS chipset and so this chipset documentation is also valid in this case.
About MAC address, I would advise to check PM0237 : BlueNRG-MS stacks programming guidelines section 3.1.1. It describes the different type of BLE MAC address and how to use them.
To make it short, this BlueNRG-MS ( and so the associated BleuNRG-M0x module) don't have a preassigned MAC address. As you mentioned, each device is having a unique id .. but this is not a preassigned MAC address.
So, you are right : BLE MAC address should be handle at application level.
There is different type of MAC address : PUBLIC, PRIVATE or RANDOM. Except is you have specific requirements, usually selecting a random mac address is preferred solution.
In this case, at very first boot, device will generate (and store) a random MAC address that will remain valid for the whole life of product.
Hope it helps,
Regards,
Sebastien.
2023-01-05 08:48 AM
Hello Sebastien,
Thank you for your reply!
So what you're saying is that I can reassign the MAC address if I wished? For example, there is a pre-defined MAC address in the code. I can change that address and it will reassign the MAC address and operate as intended still?
2023-01-05 09:02 AM
Hello @KMew ,
Yes.. this is it. Anyway, this implies you manage your own set of mac address at production level ( PUBLIC or PRIVATE : you must avoid 2 product with same MAC address)
As mentioned in my initial post : depending of your specific needs, you may simply use static random address. In this case, no need to manage BLE MAC address. This will be handled by BLE stack.
BLE stack will generates a random address at very first boot (and store into NVM memory). This address will be use for whole product life - No need to manage it at application level.
Regards,
Sebastien.
2023-01-05 11:41 AM
Hello Sebastien,
Thank you for explaining that. I am reviewing the SensorDemoBLE code with that section to try and understand it. My original question is answered, but it made me realize another.
As per the document you linked:
"The ACI command to set the MAC address is ACI_HAL_WRITE_CONFIG_DATA (opcode 0xFC0C)"
Then, in the app_bluenrg_ms.c, there is this snippet in the init section:
/*
* Reset BlueNRG again otherwise we won't
* be able to change its MAC address.
* aci_hal_write_config_data() must be the first
* command after reset otherwise it will fail.
*/
hci_reset();
HAL_Delay(100);
Two things happen that seem to go against this. If aci_hal_write_config_data() writes the MAC address and hci_reset() clears the MAC address, then aci_hal_write_config_data() should be called after the hci_reset(). However, that never happens in the sample code.
Am I missing something?
2023-01-06 01:00 AM
Hi @KMew ,
In this code example from X-CUBE-BLE1 package, I agree this comment can be misleading. This comment is valid only if you want to force a specific MAC address (customer MAC address : whatever private or public). In such case you can write this MAC address using aci_hal_write_config_data() API.
It is not possible to permanently save in BlueNRG memory a "customer MAC address". The BlueNRG-MS requires the MAC address to be set by customer after each hardware reset or HCI_RESET or power up.
Now, coming back to code example you mentioned, this code is using STATIC_RANDOM address(see code below), so nothing to do in this case.
Using static random, you don't need at all to write or manage MAC address (this is managed automatically by BLE stack). BLE stack will generate (first time) a random MAC address that will be stored in BlueNRG internal flash. BLE stack will then reuse it for whole product life.
ret = aci_gap_set_discoverable(ADV_DATA_TYPE,
(ADV_INTERVAL_MIN_MS*1000)/625,(ADV_INTERVAL_MAX_MS*1000)/625,
STATIC_RANDOM_ADDR, NO_WHITE_LIST_USE,
sizeof(local_name), local_name, 0, NULL, 0, 0);
Regards,
Sebastien.