Re: [avrdude-dev] [bug #40061] avrdude -U fails to save final FF bytes.

[Joerg Wunsch]

As Bob Cunningham wrote:

> There is no reason to use a broken tool, nor to argue with folks who have
> defended its decade of brokenness.

OK, so far about Bob.

I'd like to get opinions from others on this.

My ideas so far:

. The current behaviour has been intented as an optimization, and this
  certainly makes a lot of sense for the more common use cases
  (reading out memory to program it back later, or for some kind of
  eyeball review or disassembly).  So I don't like it to go away
  completely.

. Sure, I see Bob's point that sometimes, one might want to retain a
  full image of what has been there.

. I also see the point that with an application, followed by a
  bootloader very far away, basically the same considerations as above
  could be made to the intervening 0xFFs.  But where to draw the line?

One option for #2 were to have a separate indication that you really
want the full image, like -U flash:R:flashfile:i, where the capital
'R' indicates it.  That far, it should be simple to do.

As for #3, one idea I've got is to always consider full flash pages.
If a flash page turns out empty, omit it from the image.  That way, a
few bytes of 0xFF won't be dropped, but all large holes will.  (Such
holes are not only related to bootloaders, but could also happen if
there are separate application data.  The Xmegas even have their
"apptable" area for that purpose.)  But how to handle ancient AVRs
that don't have paged flash?  Impose some kind of artificial pagesize
just for that purpose?

Any other opinions?
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)