Two dev boards have same MAC address

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

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

We have two of the 20732 dev boards and they appear to have the same mac address: 20732A0C0FFE

This may be confusing things when we run them at the same time. 

Is there a way to configure the MAC address on these boards?

0 Likes
1 Solution
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

You can upgrade to the new 1.1 SDK and it will program some of the BD_ADDR bytes with random values. Or you can edit Platforms/BCM920732ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the value you want. To use random address instead:

DLConfigBD_ADDRBase = "20732A0*****"

where every * will be replaced with a random value.

View solution in original post

7 Replies
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

You can upgrade to the new 1.1 SDK and it will program some of the BD_ADDR bytes with random values. Or you can edit Platforms/BCM920732ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the value you want. To use random address instead:

DLConfigBD_ADDRBase = "20732A0*****"

where every * will be replaced with a random value.

What is the recommended way to configure the MAC address in a production line?  Does this need to be coded into the eeprom image, or can it be set at runtime during a manufacture test process?

0 Likes
Anonymous
Not applicable

hdf_file.PNG Hello Idgirod,

The cgs.exe in the SDK can enable the same BD_ADDR programming mentioned above but in the manufacturing process.

Here is the locationof the cgs.exe file:

cgs_exe_location.PNG

You will also need the ChipLoad.exe file located here:

WICED\WICED-Smart-SDK-1.1.0\WICED-Smart-SDK\Tools\ChipLoad\Win32

ChipLoad_exe_location.PNG

Here are the set of instructions for now - I will post an App note on the forum and send you the link.

2. Downloading the FW:


I. Required tools and files:
       1. Cgs.exe
       2. Chipload.exe
       3. Cgs file of the build application.
       4. btp file.

20732_EEPROM_btp_file.PNG
       5. hdf file.

hdf_file.PNG
       6. Minidriver - The minidriver file is in the SDK @Platforms/BCM920732TAG_Q32/uart_DISABLE…hex

II. Converting cgs file to hex file:
       1. Using command-line interface(eg. Cygwin, cmd.exe), run cgs.exe
       2. Use the following command:

             ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf> <input_file.cgs>

              output_file_name.hex – will be the converted hex file.
              btp_file.btp – btp file for the TAG.
              input_file.cgs – built cgs file for the application.
              0xFF000000 – base address for the EEPROM.
              File.hdf - directories for hdf file

Converting_cgs_to_hex_file.jpg


III. Downloading the hex file:
       1. Using command-line interface, run chipload.exe
       2. Use the following command:

        ./Chipload.exe –BLUETOOLMODE –PORT COM16 –BAUDRATE 115200nfc –MINIDRIVER
        <minidriver.hex> -CONFIG <output_file_name.hex> -BTP <btp_file.btp> -NODLMINIDRIVER

         COM16 – connected port
         Minidriver.hex – minidriver for the TAG
         Output_file_name.hex – converted hex file.
         btp_file.btp – btp file for the TAG

ChipLoad_exe_Output.jpg

And then you can see the success:

Converting_cgs_to_hex_file_Success.jpg

Again, I will post a link to an App note.

Hi JT,

Thank you for the detailed explanation.

Three further questions:

1. Our sales rep thought it was possible to get the modules pre-loaded with firmware so as to avoid having to load the firmware during manufacturing.  However it would seem that programming the MAC requires essentially generating a custom .hex file, so maybe the rep was just confused?

2. If we implement OTA upgrade, can a new FW be loaded without blowing away the previously configured MAC address or does the FW image need to be customized?

3. How are MAC addresses allocated - are there address spaces for these parts or do we get them from some global authority? 

Thanks!

0 Likes
Anonymous
Not applicable

1. Our sales rep thought it was possible to get the modules pre-loaded with firmware so as to avoid having to load the firmware during manufacturing.  However it would seem that programming the MAC requires essentially generating a custom .hex file, so maybe the rep was just confused?

[JT] - When you build using the SDK, you will see two hex files.  However, what you download in the factory is <app_name>-<platform>-rom-ram-Wiced-release.hex (and this is what the SDK does when your target is ‘download’ or ‘recover’).

So this is called the factory image and this includes the BD_ADDR.

During mass production, you should use the .cgs file + cgs.exe to generate one unique hex file per device and then use chipload.exe to download this to the NV memory.

The reason you need to do it this way is because each device needs a unique BD_ADDR and the BD_ADDR is embedded in the hex file by cgs.exe when the .hex is generated from the .cgs.

2. If we implement OTA upgrade, can a new FW be loaded without blowing away the previously configured MAC address or does the FW image need to be customized?

[JT] - OTA updates always preserve the BD_ADDR and pairing keys – only the FW/App and patch code will be replaced.

The SDK always generates a separate set of files (.ota.hex and .ota.bin) that are to be used for the OTA update (the Windows OTA update peer app expects this .bin file) – this of course assumes that you already included the code in ws_upgrade.c and implemented the hooks for it in the app, without which the .ota.* files are of no use.

3. How are MAC addresses allocated - are there address spaces for these parts or do we get them from some global authority? 

[JT] - The assignment of the MAC Addresses is done by the Bluetooth SIG - Bluetooth Site Maintenance (But they are doing maintenance today) - Please visit the site tomorrow when it's up.

JT

Thank you, JT - I appreciate the support!

0 Likes

You don't have to edit the .btp file to change BD_ADDR when generating unique .hex files during mass production. cgs.exe also accepts an override option that can override any configuration in the .btp file, including the BD_ADDR configuration.

So, from JT's step II Converting cgs file to hex file:

       1. Using command-line interface(eg. Cygwin, cmd.exe), run cgs.exe

       2. Use the following command:

             ./cgs.exe -I <output_file_name.hex> -O DLConfigBD_ADDRBase:207321234567 –A 0xFF000000 –B <btp_file.btp> -D <file.hdf> <input_file.cgs>

will set the device address to 207321234567 regardless of what is there in the .btp file. Downloading to different devices during mass production will then need two steps:

1. Generate the .hex for the device from the .cgs, override the device address using the -O option

2. Use chipload.exe to load the .hex generated in step 1.