Creating HEX File with CGS for 20736S

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

cross mob
PhGi_2174146
Level 3
Level 3
First like received First like given

We're trying to program 20736S modules from the command line.  We've found that if we use the .HEX file that was created in the IDE that we can program without issue.  However, if we use CGS.EXE to convert the CGS file (created by the IDE) into a HEX file, then the devices cannot be programmed.

This is what the output (tail) looks like when the programming fails:

...

Download minidriver successfully had written 251 bytes to address 0x0020392E

Download minidriver successfully had written 251 bytes to address 0x00203A29

Download minidriver successfully had written 251 bytes to address 0x00203B24

Download minidriver successfully had written 21 bytes to address 0x00203C1F

Download minidriver successfully had written 8 bytes to address 0x002043FC

Launch minidriver at 0x00201000 succeeded

Downloaded 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Verified 0 code bytes

( 0.0%) and 0 data bytes ( 0.0%).  Current state: Executing -- erasing chip

Chip erase in progress

Downloaded 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Verified 0 code bytes

( 0.0%) and 0 data bytes ( 0.0%).  Current state: Executing -- erasing chip

Downloaded 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Verified 0 code bytes

( 0.0%) and 0 data bytes ( 0.0%).  Current state: Executing -- erasing chip

Downloaded 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Verified 0 code bytes

( 0.0%) and 0 data bytes ( 0.0%).  Current state: Terminated with error

Download config error trying to write 40 bytes to address 0x00000000    (SOURCE:

  CONFIG  Configuration data  RELEASE.hex)

Here's the command line we're using for CGS.EXE:

    cgs.exe -I RELEASE.hex -A -0xFF000000 -B 20736_EEPROM.btp -D . --cgs-files RELEASE.cgs

Here's the chipload command line:

     chipload.exe -BLUETOOLMODE -BAUDRATE 115200 -PORT COM10 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -CONFIG RELEASE.hex -BTP 20736_EEPROM.btp -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251

When looking at differences between the HEX files, it appears the headers and what we assume are address offsets are different.

The following is the header for the HEX file created from the CGS command line above.

:020000040000FA

:28000000010800F000006208C05D89FD0400FFFFFFFF4006008497136A7320020A0000400000002000000010E5

:020000040000FA

:FB400000A21A006C3000001B33000000000000141E0802B00400000000000000007206000B0000000001B30100176902000000B80400001BB7000A05005C45200001800200F00A0A080088112000020F00000A08001411200007C900000A08004411200007C900000A08002811200007C900000A08005811200007C900000A08001011200009C800000A08004011200009C800000A08001811200008C700000A08004811200008C700000A080024112000148100000A0800541120001481000003010001821D00FF04141E325A0001000031000158FF7F00E40100E70100E90100EC01000AE40968452000044B1B884FEA1323012203200DF6B8FA11F653B931

:FB40FB00764F200000F0 ...

Here's the header in the HEX file created from the IDE (differences from prior version underlined):

:02000004FF00FB

:28000000010800F000006208C05D89FD0400FFFFFFFF4006008497136A7320020A00800500004001000000048B

:02000004FF00FB

:FB058000A21A006C3000001B33000000000000141E0802B00400000000000000007206000B0000000001B30100176902000000B80400001BB7000A05005C45200001800200F00A0A080088112000020F00000A08001411200007C900000A08004411200007C900000A08002811200007C900000A08005811200007C900000A08001011200009C800000A08004011200009C800000A08001811200008C700000A08004811200008C700000A080024112000148100000A0800541120001481000003010001821D00FF04141E325A0001000031000158FF7F00E40100E70100E90100EC01000AE40968452000044B1B884FEA1323012203200DF6B8FA11F653B9EC

:FB067B00764F200000F0 ...

From everything we've read, we should be using a parameter -A with an address of 0xFF000000.  Experimenting and changing the address to 0xFFA00000 seems to get the addresses in the hex file to line up properly, but the header is still different and the programming fails:

:020000040000FA

:28000000010800F000006208C05D89FD0400FFFFFFFF4006008497136A7320020A00800500004001000000048B

:020000040000FA

:FB058000A21A006C3000001B33000000000000141E0802B00400000000000000007206000B0000000001B30100176902000000B80400001BB7000A05005C45200001800200F00A0A080088112000020F00000A08001411200007C900000A08004411200007C900000A08002811200007C900000A08005811200007C900000A08001011200009C800000A08004011200009C800000A08001811200008C700000A08004811200008C700000A080024112000148100000A0800541120001481000003010001821D00FF04141E325A0001000031000158FF7F00E40100E70100E90100EC01000AE40968452000044B1B884FEA1323012203200DF6B8FA11F653B9EC

:FB067B00764F200000F0...

Any ideas?

0 Likes
1 Solution

JT,

Thank your for your help.  I added the VERBOSE switch and it turns out that I was supplying the same parameters in my command line... sorta

The IDE generated CGS call was using paths back to the relevant directories, where I instead had created a single directory containing all of the files that (I thought) were required.  The purpose of the single directory is to be able to load the programming capability onto a thumb drive or remote folder so that machines performing programming do not require the development environment to be installed.

I had assumed that since the -D parameter was design to point the .hdf file, all that was required was ConfigDef20732_ab.hdf itself.  However, once I copied the other files in that directory back to my single source directory - everything worked as expected.

Phill

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

Hello Phill,

I just talked to the developers:

1.  Your hex file is not at the right offset, so Your -A parameter is not taking

2.  When downloading, add  -LOGTO some_log_file.txt to see what is sent to the minidriver.

3.  Add VERBOSE=1 and see what the IDE does. Use the same parameters and files, you should get the same .hex image

Let us know your results.

Thanks

JT

0 Likes

JT,

Thank your for your help.  I added the VERBOSE switch and it turns out that I was supplying the same parameters in my command line... sorta

The IDE generated CGS call was using paths back to the relevant directories, where I instead had created a single directory containing all of the files that (I thought) were required.  The purpose of the single directory is to be able to load the programming capability onto a thumb drive or remote folder so that machines performing programming do not require the development environment to be installed.

I had assumed that since the -D parameter was design to point the .hdf file, all that was required was ConfigDef20732_ab.hdf itself.  However, once I copied the other files in that directory back to my single source directory - everything worked as expected.

Phill

0 Likes
Anonymous
Not applicable

Fantastic!

Thanks for the update

JT

0 Likes