Re: [avrdude-dev] special handling of 0xff in flash memory

[Brian Dean]

On Thu, May 22, 2003 at 06:57:30AM -0600, E. Weddington wrote:

> What about the special case where you have bootloader code at a high
> address as well as application code in the same file? You have a big block
> of valid data at the beginning, followed by a lot of "blank" memory
> (0xff), followed by valid data (bootloader code) at a high address,
> followed again by some blank memory (after the bootloader code). Will it
> handle this?

It should handle this OK, but it may not be all that useful in this
case.  The way it operates is basically to read the input file or dump
the part memory as normal, filling up the buffer area for that memory
(which was initially 0xff filled).  Then, starting at the highest
address of the memory buffer and search backwards for the first non
0xff byte.  Then return that many bytes as the number of bytes read
from the file (or memory) instead of the actual number that were read.
This causes subsequent "write" and "verify" checks to use the lower
number of bytes while doing their work.

Thus, for the case above, there won't be much savings.

But with the previous behaviour, if you dumped the flash on an
ATmega128, you got a file that contained a 128K memory section, even
if the actual program was only consuming a small fraction of that.  If
you then loaded that dumped memory back into another device, avrdude
would blindly load in the entire 128K even though most of it was
unnecessary, which was time consuming.  With the new change, only the
actual contents that contain the program are dumped to the file,
creating a smaller file.  And when loading the file back into memory,
only the portion containing actual program code is written to flash,
reducing programming time significantly by eliminating the unnecessary
0xff writes.

But the next logical thing to do, IMHO, would be to not attempt to
write 0xff when writing flash memory (only flash memory).  That would
help the above case you describe by causing the big "blank" area of
memory in between the actual program and the boot loader to be skipped
which should speed up programming time significantly, especially for
devices with large flash memories like the ATmega128.

If no one objects, I'll take a look at doing this at some point, or if
someone else gets to it first, that's fine too.  Doing this may
require a bit of code duplication since the the avr_write_byte()
routine needs to know about it, as well as any per-programmer routines
such as stk500_paged_write(), etc.  Also, this should _only_ have an
affect on "flash" memory, so a check needs to be made for the memory
type.

-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/
http://www.bdmicro.com/