Can anyone give me a reply?
in the cgs tool there is -T and -O option, use those to have your BDADDR saved.
I’m using SDK 1.1.0’s cgs, I have checked it, it do NOT include “-T” option.
When I use cgs.exe from sdk 2.2.0, it have “-T” option, can I use 2.2.0 cgs.exe to convert 1.1.0’s output *.cgs?
cgs files are just configuration files in source. you can use the cgs.exe in sdk2.2
any chance that you will migrate to 20736/7?
I think I should explain more about this issue.
We have create an utility to upgrade 20732 firmware which use cgs.exe and chipload.exe for firmware upgrade. You can see that there is a HEX box to input mac address, then we can use cgs.exe to create a *.hex file.
But our customer notice me that it’s un-convenience because they must input mac address even if they just want to upgrade firmware, be not desired to touch MAC address.
In sdk 2.2.0, I use “application-BCM920737TAG_Q32 BT_DEVICE_ADDRESS=111222333666 download VERBOSE=1” and “application-BCM920737TAG_Q32 download VERBOSE=1” to make target.
When I use “application-BCM920737TAG_Q32 BT_DEVICE_ADDRESS=111222333666 download VERBOSE=1”, mac address is 0x111222333666.
When I use “application-BCM920737TAG_Q32 BT_DEVICE_ADDRESS=111222333666 download VERBOSE=1”, mac address revert to 0x20737a189877, that is not what I want.
How can I do that?
image001.png 48.6 K
As per the “-T” option, could you give me an example command line for that? Below is what I input by command line and reason.
C:\Disk_Driver\Firmware\WirelessModem\BLE\truck\cgs>cgs.exe -I application-BCM920732TAG_Q32-rom-ram-Wiced-release.hex -A 0xFF000000 -B 20732_EEPROM.btp -D ConfigDef20732_ab.hdf --cgs-files A_20732A0-application-rom-ram-spar.cgs -T --BDADDR
cgs v1.3.5.0136 20140311
Copyright (c) 2012-2014 Broadcom Corp.
Processing cgs files: A_20732A0-application-rom-ram-spar.cgs ...
Creating Intel Hex file: application-BCM920732TAG_Q32-rom-ram-Wiced-release.hex... failed.
Reason: CBluetoolConfigProcessor::ProcessStaticSectionData : BDADDR could not be parsed.
-T option is same as --bdaddr and followed by 12 digits BDADDR.
I don't know how I can make hex file without overwriting BDADDR.
After reading this thread, as my understanding, there is no way to solve this problem. If I use chipload.exe to upgrade firmware, old MAC address will be destroyed, and new one or random one will be written into chip, right?
Let's step back for a second.
The blog here attempts to explain several options for modifying the BD_ADDR on the 2073XS: BD_ADDR: Changing BCM20737 Board Address for Production
Admittantly, both the blog and process we describe to change the BD_ADDR is not ideal, many have learned to work within the constraints we impose.
Would OTA updates be an option for your customer? The BD_ADDR is not touched using this process. If my memory serves me correctly, non-secure OTA was supported on the 20732 you are using in the design.
If this is not an option, the blog noted above attempts to explain another command line process that may work as well.
The example Perl script assumes a random number is being generated, but the script could be changed to either cycle through a block of fixed addresses starting at x and ending with y, or in your case, always contain the desired fixed value.
For example, if you look inside the .pl file, there is just a single line of code: $$r=int(rand(20480)); printf "00101801%04X",$$r; That’s really just a random number generator for the lower 12 bits of the address.
It then tacks that onto a fix value that is the upper 24 bits (BRCM OUI number).
Here’s the batch file that’s also included in the zip file attached to the blog references above:
@for /F "tokens=1*" %%i IN ('perl.exe mac.pl') DO @(
cgs.exe -D . -O DLConfigBD_ADDRBase:%%i -A 0xFF000000 -B 20737_EEPROM.btp -I output.hex --cgs-files A_20737A1-wiced_sense-rom-ram-spar.cgs
Chipload.exe -BLUETOOLMODE -PORT %1 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG output.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251
@echo Download Complete
echo BD_ADDR: %%i
This batch file appears to run on a PC and call the Perl script, generate the random BD_ADDR, then take that value (%%i ) and pass it to the DLConfigBD_ADDRBase option in cgs.exe at the address of 0xFF000000.
Chipload is then called to program the part with the new random address.
So what it would essentially do is look at your hex file, program the BD_ADDR at the address specified, load the hex file onto your customer's board.
<wait for user input>
They would then swap out another one of thier boards look at your hex file, program the BD_ADDR at the address specified, load the hex file onto the board.
<wait for user input>
Continue process until all of the boards are updated.