• MPLAB XC8
  • Hexmate checksum calculation without filling unused memory
2020/03/02 08:47:10
rioru
Hello.
I'm using PIC18 K42, XC8 2.10.
I want to write the checksum of user program into an eeprom location. The hexmate command is following:
2000-ffff@310000,width=-2,algorithm=2

Only half of the specified memory range is actually used. Hexmate fills the rest of the memory with FFs, correctly calculates the checksum and puts the 'filling' into a .hex file as a bunch of FF-lines.
Can I somehow tell hexmate to treat the unused memory as FFs, but to not actually write them into a .hex file?
Thank you.
2020/03/03 14:49:37
mlp
rioru
Can I somehow tell hexmate to treat the unused memory as FFs, but to not actually write them into a .hex file?

So, you want Hexmate to state as a fact something it cannot possibly be sure of? (that all unmentioned Flash is 0xFF)
 
That's not what Hexmate is for. (Source: used to be able to roll a scrunched-up ball of paper at, and hit, the desk of the bloke who originally wrote Hexmate from my own desk. Hi, Garth!)
 
And why would you do it, anyway?
 
You've stated that half of the memory is used, so you save at most half of your programming time if your hex file omits the unused words.
If "half of your programming time" approaches the total of your own and others' time looking into an answer for your "lie about the checksum" question, you should probably be paying for the chips to be bulk-programmed before they reach you[r assembly house].
2020/03/03 16:48:39
ric
I'm guessing this is aimed at a system with a bootloader, and he's trying to keep the blank section out of the file sent to the bootloader.
 
2020/03/03 21:35:00
rioru
Thank you for your replies.
First of all, the fact that unused Flash are all FFs is not a lie. Flash is always erased first and then programmed, so if a flash memory region is not present in a hex file, then it's safely can be assumed to be all FFs.
mark.pappin
And why would you do it, anyway?

There are several reasons for that:
1. In bootloader, validity of the user program is verified by calculating checksum of the whole user flash memory. Bootloader doesn't know how much of the user flash memory is actually used and has to calculate over entire user space, including all the unused space, which are FFs.
2. If I explicitly fill the unused space with FFs, so hexmate could properly calculate the checksum, as I already mentioned, it will put them in a .hex file as a bunch of useless FF-lines, which will increase the programming times (especially in bootloader, where program is transfered using UART).
3. The FF-fill also messes up the cipher program, which parses and encrypts the .hex file.
2020/03/04 08:35:38
aschen0866
If you call hexmate (using a batch/script) without the -FILL option as part of post-build process, I don't think it will fill unused locations with FF automatically. Additionally, you can add -LOGFILE=my_hexmate.log to the batch file and the log file will show how memory locations are filled.
Example without the -FILL option (for PIC32)

### Hex Memory Map ###
Legend:
- = Unused memory
F = Filled ROM
S = Stored serial code
A = Stored ASCII string
R = Reserved for checksum
C = Stored checksum result
T = Trailing code
& = Find & replace opcode
X = Find & delete opcode
1 = dist\RELEASE\production\Test_Btl.X.production.hex
00000000: ----------------------------------------------------------------
1FC00000: 1111111111111111111111111111111111111111111111111111111111111111
1FC00040: 1111111111111111111111111111111111111111111111111111111111111111
1FC00080: 1111111111111111111111111111111111111111111111111111111111111111
1FC000C0: 1111111111111111111111111111111111111111111111111111111111111111
1FC00100: 1111111111111111111111111111111111111111111111111111111111111111
1FC00140: 1111111111111111111111111111111111111111111111111111111111111111
1FC00180: 1111111111111111111111111111111111111111111111111111------------
1FC00380: 1111111111111111------------------------------------------------
1FC00480: 11111111111111111111111111111111111111111111----1111111111111111
1FC004C0: 1111111111111111111111111111111111111111111111111111111111111111
1FC00500: 1111111111111111111111111111111111111111111111111111111111111111
1FC00540: 1111111111111111111111111111111111111111111111111111111111111111
1FC00580: 1111111111111111111111111111111111111111111111111111111111111111
1FC005C0: 1111111111111111111111111111111111111111111111111111111111111111
1FC00600: 1111111111111111111111111111111111111111111111111111111111111111
1FC00640: 1111111111111111111111111111111111111111111111111111111111111111
1FC00680: 1111111111111111111111111111111111111111111111111111111111111111
1FC006C0: 11111111111111111111111111111111111111111111111111111111--------
1FC01000: 1111111111111111------------------------------------------------
1FC01100: 1111111111111111------------------------------------------------
1FC01180: 1111111111111111------------------------------------------------
1FC01200: 11111111--------------------------------------------------------

With the -FILL option

### Hex Memory Map ###
Legend:
- = Unused memory
F = Filled ROM
S = Stored serial code
A = Stored ASCII string
R = Reserved for checksum
C = Stored checksum result
T = Trailing code
& = Find & replace opcode
X = Find & delete opcode
1 = dist\RELEASE\production\Test_Btl.X.production.hex
00000000: ----------------------------------------------------------------
1FC00000: 1111111111111111111111111111111111111111111111111111111111111111
1FC00040: 1111111111111111111111111111111111111111111111111111111111111111
1FC00080: 1111111111111111111111111111111111111111111111111111111111111111
1FC000C0: 1111111111111111111111111111111111111111111111111111111111111111
1FC00100: 1111111111111111111111111111111111111111111111111111111111111111
1FC00140: 1111111111111111111111111111111111111111111111111111111111111111
1FC00180: 1111111111111111111111111111111111111111111111111111FFFFFFFFFFFF
1FC001C0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1FC00200: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1FC00240: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1FC00280: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1FC002C0: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1FC00300: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1FC00340: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
1FC00380: 1111111111111111FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

2020/03/04 08:53:40
rioru
That's true, aschen0866. If you call hexmate -CK without -FILL, then it will treat unused memory as 0x00, not 0xFF like I wanted. I guess hexmate just has no such functionality.
2020/11/24 16:35:36
olso4539
I know the thread is old, but there's an easy solution. Use a temporary file. You should fill, calculate the checksum/crc, and store the output in a temporary file. Then combine the two files, pulling only the checksum memory range from the temporary file. As an example with arbitrary memory ranges, fill, crc setting etc.
 
1. Fill and calculate crc, store in temp file
2. Strip down temp file to crc only for easier viewing/debugging
3. Combine desired memory ranges (i.e. application memory range) with the crc file
 
hexmate inputFile.hex -ocrc.hex -FILL=w1:0xFF,0xFF,0xFF,0xFF@0x20000:0x9FFDF +-CK=20000-9FFDF@9FFE0w-4g5p04C11DB7

hexmate r9FFE0-9FFE3,crc.hex -ocrc.hex

hexmate r20000-9FFFF,inputFile.hex +dist\default\production\crc.hex -oinputFile.hex
© 2021 APG vNext Commercial Version 4.5

Use My Existing Forum Account