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

[johan at edab.nu]

I would read out the whole software twice, after downloading it with the two methods repectively, saving the two files in a common format (hex) and compare the results using Beyond Compare 2 (google for it) and see what the differences are. For example you might see that in one case the unused bytes are FF and in one case they are 00. Or it might be something else..


On 2008-05-28 Bate Michael  wrote:

I was the original poster of this query.
>
>Unfortunately the question that I asked has not been addressed, so I'm trying again.  Instead we have got bogged down in a discussion of CRC algorithms and how to implement them.
>
>My question was: Is there any reason why the program images (as stored in the atmega168) loaded from a .COF file should be any different from that loaded from the corresponding .HEX file (generated at the same time by the Imagecraft compiler, which supports creating both files simultaneously)?
>
>Someone suggested that maybe debug information is being loaded to the atmega168 from the .COF file, but I'm not sure that makes any sense.  Then again I don't have a good understanding of the details of how the JTAG ICE mk2 works, in conjunction with AVR Studio.  I understand that the .COF file contains lots more information (for debugging) but does that affect what is loaded to the chip?
>
>I could understand how these images might be different due to unused bytes, but I specified to the compiler that these bytes should be set to zero.
>
>We got sidetracked into a discussion of CRCs because I made the mistake of mentioning that that was how I knew that the program images were different.  I even included the CRC algorithm (or part of it) in my original message.  That was clearly a mistake.
>
>Michael Bate
>
>_______________________________________________
>Icc-avr mailing list
>Icc-avr at imagecraft.com
>http://dragonsgate.net/mailman/listinfo/icc-avr
>
>