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

[Bate, Michael]

Rich,

Thanks for the reply.

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.

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

- Michael Bate


Message: 2
Date: Thu, 22 May 2008 19:38:14 -0400
From: Rich Webb <webbra.mlist at verizon.net>
Subject: Re: [Icc-avr] Different executable images with .COF and
	.HEX??
To: icc-avr at imagecraft.com
Message-ID: <483603E6.3000701 at verizon.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> I have implemented an algorithm to calculate the CRC of the program
> memory on our Atmega168 (see code below).
> 
> I was surprised to see that the resulting CRC is different if the
> program memory is loaded from the .COF instead of the .HEX file.
> 
> I have the compiler option "Unused ROM Fill Bytes" set to 00.

Unused (genuinely unprogrammed) bytes will be 0xFF so perhaps there's a 
difference in how the two formats (COF vs HEX) handle unused regions 
with that option checked?

I'm not that familiar with COF, but in the HEX format the individual 
lines contain address offsets, so "unused" bytes may not necessarily 
(and probably won't) even appear in the file.

Unless you have an overriding need to zero the unused bytes, I'd just 
leave them alone. Makes for a smaller file, faster load.