Re: [avrdude-dev] Possible bug in S-record output

[Brian Dean]

On Tue, May 20, 2003 at 11:24:49AM +0300, Alexey V.Levdikov  wrote:

> This happens when all memory block contains only 0xff , then all
> unprogrammed bits are skipped and only s9 record in the .s19 file
> presents. S-record type S9, indicating it is a termination record.

Alexey, I can see where this might be an optimization in the case of
flash memory, but this may not be entirely correct for memories that
have an autoerase cycle like eeprom and fuse bits.  For example, if I
dump the eeprom from a part that has 0xff for the first, say, 100
bytes, then non 0xff data following, the s-rec routine would skip the
first 100 bytes and create the output file with a non-zero start
address.  But then if I reload that data into another chip that has
non 0xff data in the first 100 bytes, the result won't match the
contents of the chip that I just dumped because the first 100 bytes
will be untouched.  Or am I mis-interpreting how the b2srec() routine
works?  I think that it would be non-intuitive to dump the memory of
one chip and reprogram another chip with that memory dump and possible
end up with different memory contents for the two chips.

What do you think about modifying the srecord output routine to be
more like the ihex and raw output routines which bascially just dump
the range provided regardless of the contents?

At any rate, it seems as though there may be some other problem at
work with Tom's error since the data he was dumping was not 0xff.
Perhaps an off by one bug or something?  If so, I haven't yet spotted
it.

Cheers,
-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/
http://www.bdmicro.com/