"Cunningham, Robert" <[email protected]> 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. ;-) _______________________________________________ AVR-chat mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avr-chat
