Field upgrade BCM module firmware via PUART - MAC ADDRESS?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
dasmc_2125571
Level 4
Level 4
5 likes given First like received First like given

I am currently adding the ability to update the BCM module's firmware via the puart from our main system micro to enable in field programming of firmware updates.  This is based on the example project, "uart_firmware_upgrade".  A question that arises is that of MAC address after the update.

I've seen other threads that indicate that the MAC address can't be set at runtime via an API call -- that it has to be added to the binary file via an external tool. The issue that I'm trying to determine how to address is that a single binary image will be sent to all devices in the field for the purpose of field firmware upgrade.  It seems this will result in all upgraded devices having the same MAC address.

Is there a solution to this problem that doesn't require a unique file to be built for every device in the field?

Thank you,

David

0 Likes
1 Solution
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

With regard to the patch, called bd_addr_control.a, it's contained in the latest SDK 2.2.2. You'll need to add this file to your apps makefile and #include the .h in your app.

          APP_PATCHES_AND_LIBS += bd_addr_control.a

.h is located at:

WICED-Smart-SDK-2.2.2/Wiced-Smart/tier2/brcm/libraries/inc/blecm_set_static_bd_addr.h

In the .h you'll find a description of the function and how to call it.

Jacob

View solution in original post

13 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

jaeyoung​ and others on the team are looking into doing this at runtime, but it doesn't appear that there are many options.

At this point, changing the BD_ADDR requires a unique build as described above and in this discussion: Re: Need to program a certain Bluetooth address into my device....

Note that we have made some progress with Avnet (our distributor) and their programming center to enable this ability (unique BD_ADDRs) in production, so that could be another option.

JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

Hi dsmith@medeco.com​,

You can manually overwrite the section of NVRAM where the BD_ADDR is held and put your own value in it's place. Write the new BD_ADDR over PUART, then write that value to the EEPROM at the appropriate address via i2c. The address isn't check-summed so no errors will be thrown on the next boot up.

Unfortunately, our bleprofile_WriteNVRAM API will return without doing anything if you try to write above 0x7C. So this means that you will have to write your own driver for the EEPROM and overwrite the section manually.

Secondly, if your BD_ADDRs are allowed to be random, there does exist a patch in the latest SDK that will set your BD_ADDR to a random value at run time. Assuming you want to specify your BD_ADDRs, there may be a possibility of releasing a new patch in the next SDK release which will allow you to specify the new BD_ADDR at runtime with a simple API call.

Jacob

dasmc_2125571
Level 4
Level 4
5 likes given First like received First like given

Thank you jakewtorres and mmf_mmfae.  That is valuable information.  I have a followup couple of questions based on your answer.

1) Random MAC addresses would work fine for us.  Which SDK version has the ability to choose random MACs at runtime?  How is the feature selected?

2) Is the BD_ADDR value at the same location in firmware binary image each time?  If so, does it seem possible that we could overwrite it in the binary file before programming that binary into the ble module over the PUART?  What I'm thinking is that our main micro on the product could do this before the file is loaded into the ble module.

Thanks for the assistance.

Regards,

David

0 Likes

jakewtorres​ will need to respond to item 1 as I am only familiar with changing BD_ADDRs randomly as described here: BD_ADDR: Changing BCM20737 Board Address for Production

For item 2, the BD_ADDR is not part of the static section (SS) checksum (only the first 11 bytes of the SS are checked, and BD_ADDR is higher up in the NV), so you could modify this and not affect the existing checksum.

There is a BCM20732 Memory Map Architecture​ document here which explains how the NVRAM is laid out.

JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

With regard to the patch, called bd_addr_control.a, it's contained in the latest SDK 2.2.2. You'll need to add this file to your apps makefile and #include the .h in your app.

          APP_PATCHES_AND_LIBS += bd_addr_control.a

.h is located at:

WICED-Smart-SDK-2.2.2/Wiced-Smart/tier2/brcm/libraries/inc/blecm_set_static_bd_addr.h

In the .h you'll find a description of the function and how to call it.

Jacob

dasmc_2125571
Level 4
Level 4
5 likes given First like received First like given

Thanks for the additional information.  I'm currently using SDK 2.2.1.  Is 2.2.2 released?  Does it install over 2.2.1 or in parallel?

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

This patch appears to be available in the older SDKs as well (looking at 2.2.0 right now).

But yes, 2.2.2 is released and found on the Downloads page: WICED Bluetooth Documents & Downloads

It runs as a separate SDK all together, no interdependence.

Jacob

dasmc_2125571
Level 4
Level 4
5 likes given First like received First like given

** Update for the benefit of others implementing firmware loading to the BLE module **

During the process of developing this feature, I discovered that not being able to dynamically update the MAC address is a non-problem (with regard to this issue).  My initial assumption was that the MAC address was in the code image that I'd be sending to the ble module as part of an in-application programming (IAP) firmware upgrade.  This assumption was incorrect, however.  As can be seen when comparing the .hex and .ota.hex files in the build directory, the file that gets produced for the initial programming at build time (.hex) includes the MAC address generated at the time that the image is compiled.  The .ota.hex file (or ota.bin file) is the file used for IAP in-field firmware upgrades.  It doesn't include the code block with the MAC address, so the MAC address is unchanged by the IAP firmware update process.

The life-cycle process and involvement of the MAC address is as follows:

FACTORY PROGRAMMING:

1) The ble program is compiled or the production tools are used to give the image a unique MAC (say MAC-1).

2) The ble module is programmed with the image (.hex or .elf) which assigns its MAC (MAC-1).

IAP FIELD FIRMWARE PROGRAMMING:

1) The new ble firmware is compiled.

2) The ota.hex (or ota.bin) file is used to perform the IAP firmware update to the ble module.

3) The MAC is unchanged from the original (MAC-1) because the ota.hex (ota.bin) doesn't overwrite the section of the ble module's code containing the MAC address.

So in summary, in field firmware updates (through PUART in my case) DO NOT change the MAC address.  I had originally thought that the MAC would be overwritten when the IAP firmware was loaded, but this was incorrect.  As a result, there is no need to be able to reprogram the MAC dynamically in this instance.

Regards,

David Smith

Thanks for providing this level of detail for the benefit of others dsmith@medeco.com

0 Likes
dasmc_2125571
Level 4
Level 4
5 likes given First like received First like given

As a further update, we've successfully implemented the method that jakewtorres​ (Thanks!) references by using bd_addr_control.a.  His method allows the BCM2073X to randomly choose a MAC address during its first powerup following factory programming.  From this point on, it uses that MAC address.  This is very useful to prevent all manufactured devices from having an identical MAC, or to prevent having to initiate a separate build to randomize the MAC for every device programmed.

The steps we used are:

1) Followed the instructions that jakewtorres​ included in the answer to this post -- specifically include the bd_addr_control.a reference in the project makefile, copy the 'blecm_set_static_bd_addr.h' file to the project directory, and #include it in the source code.

2) Create a build target that assigns a MAC address of  0xFFFFFFFFFFFF (as required by 'blecm_set_static_random_bd_addr' in 'blecm_set_static_bd_addr').  This is accomplished by using 'BT_DEVICE_ADDRESS=FFFFFFFFFFFF download' in the build target name.

3) In the '..._create(void)' function in the main application source file, we included the following code to convert the default FFFFFFFFFFFF MAC into a randomized one ...

  // If MAC address 0xFFFFFFFFFFFF (ie. "factory fresh"), randomize it and save it to NV memory.

      {

     UINT8 new_bd_addr[6];    // At least 6 bytes to hold new MAC
     blecm_set_static_random_bd_addr(new_bd_addr);

      }

This randomization occurs only 1 time -- 'blecm_set_static_random_bd_addr' will only change the MAC if it is FFFFFFFFFFFF.  After it has been changed to a different value and saved to NV ram, the code snippet will no longer have any noticeable effect.

David Smith

JoSu_1330331
Level 2
Level 2
5 likes given First like received First like given

dsmith@medeco.com

Thanks for the post as this is helpful.

After implement and test this method:

     make image with fixed BT_DEVICE_ADDRESS=ffffffffffff mac address

     add APP_PATCHS_AND_LIBS+= bd_addr_control.a in makefile.mk

     add blecm_set_static_random_bd_addr(new_bd_addr); and related command.

The method could generate random mac address in first time execution.

But, these mac address could be generated the same one, when I programmed same device several times.

The reason is caused by the same chip, or not! I don't know.

Have any one progressed this part with different experiences?

Best Regards,

Joy Sun

0 Likes

One other user has reported this in the past.

What's happening is the RNG hasn't had enough time to warm up so the ROM resorts to a pseudo-random list which is identical on every chip.

Wait as long as possible to call blecm_set_static_random_bd_addr to allow the RNG to warm up. It will only delay BD_ADDR instantiation on the very first boot, after that, the API has no control over your BD_ADDR.

Jacob

0 Likes
JoSu_1330331
Level 2
Level 2
5 likes given First like received First like given

Moveing the function call, blecm_set_static_random_bd_addr(), to front of advirtisement function call, bleprofile_GenerateADVData(), I think, it is most far awary from initial power up.

After movement as mention as above, It could be reduce the trouble, same MAC address, happen rate.

Re-programming 20 times, it only happen at the number 8th, 19th & 20th.

Compare with the record before movement, the test of 20 times, it happen on the 6th, 7th, 11th,13th, 16th, 17th, 18th, & 20th times.

For your reference, both of this test was done on same device.
For my application, this is good enough. 

Thanks.

Best Regards,

Joy Sun