Re: [avrdude-dev] chip_erase and cycle_count cleanup

[Jan-Hinnerk Reichert]

On Sunday 30 November 2003 21:13, Brian Dean wrote:
> On Sun, Nov 30, 2003 at 08:35:52PM +0100, Jan-Hinnerk Reichert 
wrote:

> > I mean enqueue the erase operation in "updates" and have it done
> > in do_op(). And perhaps make it selectable by "-U", later.
>
> Ah, ok.  I'm not sure this is really necessary, though.  It would
> make parsing the -U option more difficult and the parameters don't
> really fit the -U option.  For example, an erase unconditionally
> erases the FLASH and sometimes the EEPROM on some parts depending
> on current fuse bit settings.  Thus, supply the <memory> field of
> the -U parameter does not apply and would be confusing.  Also, the
> <filename>:<type> fields do not apply either.

Okay, then skip the "-U" part.

> > This way you can do things like Read EEPROM, Erase, Write Flash,
> > Rewrite EEPROM in one call.
>
> You can do this now.  Remember, unless specified otherwise, an
> erase is performed before writing FLASH memory:
>
>       avrdude -p <part> -U eeprom:r:ee_save.hex:i -U flash:w:test.hex -U
> eeprom:w:ee.hex

Unfortunately, this does the erase _before_ the read of the EEPROM. If 
you do the erase in do_op(), you could insert an erase just before 
the first write.

However, it is not 100% clear, where the erase should be placed.

So, let's try a theoretical approach:
What we want, is that multiple -U options give the same result as 
multiple invocations with the -U options passed one at a time.

For this, we need to do a chip erase just before every flash write (I 
don't really think that someone will try multiple flash writes in one 
invocation, but he is certainly allowed to ;-)

However, a user might think that it is perfectly okay to do:
  avrdude [...] -U eeprom:w:ee.hex -U flash:w:test.hex

If we change the autoerase behaviour to do an erase before the eeprom 
write, the user gets what he wants, but it is different from:
  avrdude [...] -U eeprom:w:ee.hex
  avrdude [...] -U flash:w:test.hex

So either we leave behind the theoretical approach or we forbid 
combinations that could lead to unexpected behaviour (from the user's 
perspective)

BTW: I don't think that any of this is urgent, since I haven't seen 
any complaints about strange behaviour, yet.

/Jan-Hinnerk