Re: [avrdude-dev] chip_erase and cycle_count cleanup

[Brian Dean]

On Sun, Nov 30, 2003 at 10:53:52PM +0100, Jan-Hinnerk Reichert wrote:

> However, I'm still unsure about a few things.
> - I have added a check, so that cycle count isn't tracked, if it can't 
> be read before erase. Is this the right thing to do?

Sounds reasonable.  If it cannot be read, it cannot be updated.

> - Why is cycle count reset at 0xffff?

Good question.  I think this is a bug.  I think it should be compared
against 0xffffffff.  A long time ago the cycle count was 16 bits, but
was later changed to 32 bits.  This code was progably missed.

The idea here is that if '-y' is specified, but we are using a blank
chip, i.e., one where -Y has never been used, just assume that
0xffffffff means 0 for the cycle count instead of forcing someone to
initialize the cycle count to 0 first.

At least that is what I think.  I've been tracking down the origin of
that code via CVS.  Funny how we come full circle - there actually
used to be an avr_chip_erase() function in avr.c and that is where the
cycle count code eventually ended up (moved from main.c).  Later, the
avr_chip_erase() function became the pgm->erase() function for each
programmer, and at that time there were only 2 programmers: ppi and
stk500.

> - How is the cycle counter protected, when eeprom is written?

It is not, though unless the length of the EEPROM extends to the last
4 bytes, the cycle count should be left alone since a normal EEPROM
write only writes up to the point where there was data supplied by the
input file.  The exception to this would be if someone dumped EEPROM
to a file, then reuploaded it, making it look as though there was
valid data up through the highest EEPROM address.  That would restore
the cycle count to whatever it was when the EEPROM was dumped.

-Brian