[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] Possible bug in S-record output
From: |
Alexey V.Levdikov |
Subject: |
Re: [avrdude-dev] Possible bug in S-record output |
Date: |
Wed, 21 May 2003 16:31:13 +0300 |
User-agent: |
KMail/1.5 |
В письме от Ср 21 Май 2003 04:14 Brian Dean написал:
> 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.
Brian ,I think, this also isn't quite correctly because you would get the same
error in case when you dump the eeprom from a device that has less memory
than the part you attempt to load this file into. But in general, I agree
that 'srec' and 'ihex' subroutines must operate memory identically in order
to avoid such uncertainities. I've removed all unnecessary code and fixed a
bug (in the removed code :-() that I think was a cause of all these problems.
--
Alexey V.Levdikov
P.S. This latest CVS version fileio.c with changes in b2srec()
fileio.c
Description: Text Data