- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Labels:
-
FlashEEPROM
-
Manufacturing and Test
-
SDK 2.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fantastic!
Thanks for the update
JT