Re: [avr-chat] avrdude flash size less than device capacity?

[Joerg Wunsch]

"Cunningham, Robert" <address@hidden> wrote:

> 1.       Why is avrdude doing this?

Since the most common use cases benefit from this optimization.

As already told in response to the bug report, NOR flash cannot be
"programmed" to 0xFF, but only erased to it.  Thus, after a chip
erase, any cell where the input file is 0xFF does not need to be
touched at all.

Common use cases include:

.. You want to keep the file in order to later re-program it.  By the
  time this was implemented, the only way for this was a full chip
  erase before, so this case was covered well.  (Meanwhile, with the
  Xmega, one can also erase single pages only.)  Not over-programming
  the unused 0xFFs can save a lot of time if only a small percentage
  of the device memory has been in use before.

.. You want to analyze it.  If you "eyeball-review" it, the trailing
  0xFFs are merely non-information for you.  Leaving them out gets you
  a better overview of which part of the flash was actually in use.
  If you want to disassemble the result, trailing 0xFFs will generate
  additional garbage from the disassembler.

That doesn't mean your use case (later verification) is not a valid
one, but it's certainly a less common one.  But even your case is
basically already achievable right now: just read the device's flash
contents back at that later point in time, and compare both files.
If someone added more bytes behind the first file's length meanwhile,
the difference will become obvious in the files.

> 2.       Is there a way to force avrdude to do a full 32K download?

See the developers list, it's probably not too hard to add this.

-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

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