[Icc-avr] Different executable images with .COF and, .HEX??

[Rich Webb]

> I thought that setting the "Unused ROM Fill Bytes" to 00 ensured that
> all bytes were defined in the .COF and .HEX files, and that therefore
> unused bytes should not be responsible for what I am observing (that the
> loaded program image appears to be different depending on whether .COF
> or .HEX is used; note that both files are created by the compiler at the
> same time).
> 
> The reason we use this option is as a safety precaution - this is a
> medical device.  Whenever the firmware starts up, we calculate the CRC
> and verify that the program image has not been corrupted.

I use a similar process in my production code, using steps like Hartmut 
outlined:
-- Convert the hex file to a binary image
-- Run the binary image through a CRC generator
-- Convert back to a hex file
-- Program

My CRC generator is something I wrote ages ago, taking arguments of an 
input file name and a desired final file size. The output file will then 
CRC to zero if it is unmodified. All I need to put in the source code is 
the expected total file length, where the final CRC word will be stored. 
It's all automated with a single definition in the makefile.

> Before we set the "Unused ROM Fill Bytes" the CRC would be different on
> different chips so it was impossible to implement this verification.

I don't understand how this could happen, since an erased chip should 
always be filled with 0xFF. I guess it could be a side effect of the COF 
format, but I'll admit to ignorance there as I pretty much stay with the 
HEX format.