How can I use cgs.exe to convert *.cgs to *.hex but keep MACADDR the same?

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

cross mob
Anonymous
Not applicable

Hello,

I am using bcm20732s on v1.1.0 sdk, I can use cgs.exe to convert *.cgs to *.hex which contain MACADDR, then I use chipload to upgrade 20732's firmware.

But by now, I want to just convert cgs to hex without MACADDR change, it mean that the convert do NOT touch MACADDR area. So how can I do that?

0 Likes
1 Solution

Kai,


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.

View solution in original post

10 Replies
Anonymous
Not applicable

Can anyone give me a reply?

0 Likes

in the cgs tool there is -T and -O option, use those to  have your BDADDR saved.

hth

vik86

0 Likes
Anonymous
Not applicable

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?

0 Likes

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?

0 Likes
Anonymous
Not applicable

Hi boont,

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?

Best Regards,

Ren Kai

0 Likes
Anonymous
Not applicable

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.

Best Regards,

Ren Kai

0 Likes
Anonymous
Not applicable

-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.

0 Likes

this thread uses the -o option. check out the last reply...

Two dev boards have same MAC address

0 Likes
Anonymous
Not applicable

@boont

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?

Regards,

Ren Kai

0 Likes

Kai,


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.