- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
You will also need the ChipLoad.exe file located here:
WICED\WICED-Smart-SDK-1.1.0\WICED-Smart-SDK\Tools\ChipLoad\Win32
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.
5. hdf file.
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
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
And then you can see the success:
Again, I will post a link to an App note.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, JT - I appreciate the support!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.