Re: [avrdude-dev] chip_erase and cycle_count cleanup

[Brian Dean]

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

> 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.

Oops, yes, you are correct.  The reason it's like this now is so that
FLASH and EEPROM operations could be specified in any order on the
command line and the result would be the same.  Consider:

     avrdude ... -U eeprom:w:ee.hex -U flash:w:f.hex
vs.
     avrdude ... -U flash:w:f.hex -U eeprom:w:ee.hex

This could potentially result in two different outcomes if the erase
were done immediately before writing the flash, and may be confusing
to folks.  Thus, all requested memory operations are examined, and if
any of them write to flash, then a single chip erase is performed
before anything else, as if '-e' had been specified.  We discussed
this perviously and agreed that this should cover most cases.  It is
also stated in the man page - see the '-D' option description which
disables this behaviour.  A mention of this should probably also be
made in the description of the '-U' option.  My bad that it's not
there since I implemented -U.

But, if you wanted to be able to read out memory to save it, erase the
chip, then rewrite it, all in 1 invocation, then in that case creating
an 'erase' operation to insert into the 'updates' linked list at the
appropriate place would be fine.  I just wouldn't want it to be
explicit using '-U'.  Maybe do it with '-e'.  The changes are very
minor to make that happen.

If you make '-e' insert an erase operation into the 'updates' linked
list of operations, then you get what you originally wanted with -U,
but without overloading -U with additional syntax.

IMO, if you did that, the logic should be something like this:

        a) When using -U, and unless -D or -e is specified, perform
           and erase before the first "write" operation of any memory
           type if any of the memory write operations are for the
           FLASH.

        b) If '-e' is specified, then insert the erase wherever it is
           in the sequence of options.

This makes the assumption that if someone explicitly requests an
erase, they don't want the implicit "auto" erase.  That's the way I'd
want it to work anyway, others may have other ideas.  However, it also
means that the '-e' option becomes dependent on its position on the
command line - and _this_ may be confusing to some since it has always
been an on/off position-independent option before.

However, doing a) would cover nearly all cases.  I cannot really think
of a case where it would not do the right thing.

For example:

        avrdude -p <part> -U eeprom:r:ee_save.hex -U flash:w:f.hex -U 
eeprom:w:ee.hex

That would perform 1 erase just before the flash, and would be
equivalent to:

        avrdude -p <part> -U eeprom:r:ee_save.hex -e -U flash:w:f.hex -U 
eeprom:w:ee.hex

It really probably doesn't make sense to perform multiple erases with
a single invocation of AVRDUDE.  At least, I can't think of a
non-contrived case where that would be useful.

Personally, I doubt that I would do this in one command line.  I would
probably be worried that something would go wrong during the first
read that might fail, but the following erase and updates would work,
and I would end up losing the original contents of the memory that I
was trying to save.  But just because I wouldn't use it, doesn't mean
others shouldn't if they want to live dangerously :-)

> 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.

I don't necessarily agree here.  Using multiple -U's all on 1 command
line vs across seperate command lines will result in different
outcomes.  This is by design.  -U has an implied auto erase only if
FLASH memory writes are specified, unless -D was specified.  If
someone invokes AVRDUDE to write eeprom, then flash in two seperate
invocations without specifying -D on the second invocation, then they
will get what they deserve for not reading the Atmel datasheets for
what happens when a chip erase is performed and for not reading the
AVRDUDE man page.

The auto erase behaviour was implemented just recently, in fact,
because people were either forgetting to erase the part first with
'-e', or they thought AVRDUDE was going to do it for them
automatically like AVR Studio apparently does.  The reason the erase
happens before any other memory operations now is so that one could
specify the memory operations in any order on the command line and get
the same result, i.e., only 1 erase is performed and it happens before
anything else.

Some ATmega parts, though, have a fuse bit setting where an erase
leaves the EEPROM intact.  Thus, writing EEPROM followed by an erase,
followed by writing the flash, does actually result in both FLASH and
EEPROM being what the person most likely intended.

> 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

Yes, see above.

> 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

Which, IMO, is how it should be.  If one doesn't want the implied auto
erase, then use -D.

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

At most, I think that the erase could be moved from preceding _all_
memory operations, to preceding the first write operation.  I think
limiting to a single 'erase' per invocation is fine.  The folks that
are intent on performing multiple FLASH write operations on a single
command line must be so rare as to be nearly non-existant.  It just
doesn't make sense to do that.

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

Agreed.

-Brian