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

[Albert vanVeen]

Yes, I wonder how many people have spent hours inventing this wheel:
Generate an overall CRC,
Store it in a specified location of the binary file,
Check it occasionally at runtime.

Plus the verification guys who keep pestering me "how to check it", because the Fire Service standard actually specifies such a function. 

Albert.


-----Original Message-----
From: icc-avr-bounces at imagecraft.com [mailto:icc-avr-bounces at imagecraft.com] On Behalf Of Bengt Ragnemalm
Sent: Monday, May 26, 2008 05:39 PM
To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.'
Subject: SV: [Icc-avr] Different executable images with .COF and, .HEX??

Is it so far away to ask for that the compiler have the option to generate a CRC word? This feature is very common so it would be a natural feature.

/Bengt

> -----Ursprungligt meddelande-----
> Från: icc-avr-bounces at imagecraft.com [mailto:icc-avr- 
> bounces at imagecraft.com] För Rich Webb
> Skickat: den 23 maj 2008 20:27
> Till: icc-avr at imagecraft.com
> Ämne: Re: [Icc-avr] Different executable images with .COF and, .HEX??
> 
> > 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.
> 
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr


_______________________________________________
Icc-avr mailing list
Icc-avr at imagecraft.com
http://dragonsgate.net/mailman/listinfo/icc-avr

Scanned by Bizo Email Filter