avrdude doesn't properly write long series of 0xFF

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make an array of at least a page of 0xFF in progmem.
2. Try to read it from inside your Arduino sketch.
3. Notice!  The page will contain whatever the memory contents were the
last time you programmed the chip!

What is the expected output? What do you see instead?
I expect to see a big long series of 0xff, and instead, I see whatever was
on the chip before.

What version of the Arduino software are you using? On what operating
system?  Which Arduino board are you using?
I am using Arduino-0018 on Ubuntu, with a variety of Arduino boards.

Please provide any additional information below.

I first noticed this a few days ago:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1272593798/111#111

I reported this upstream, but I noticed that there is a version of avrdude
in the arduino tree, so I figured I'd report it here as well.

I dug around the source, and I narrowed the issue down to
stk500_paged_write in stk500.c, there's a check for stk500_is_page_empty.
If the whole page consists of 0xFF, the page isn't written.  This assumes
the page/chip has been erased. Autoerase is turned off in arduino, so this
is an incorrect assumption.

I commented out

/* Only skip on empty page if programming flash. */
if (flash) {
if (stk500_is_page_empty(addr, block_size, m->buf)) {
continue;
}
} 

in stk500.c, and this fixes the issue, increasing accuracy at the expense
of write speed.

I'm not sure of how it usually works, if you usually wait for upstream to
fix, or whatnot, but I thought I'd let you know.  Thanks!

Original issue reported on code.google.com by adamww...@gmail.com on 7 Jun 2010 at 3:48

[GoogleCodeExporter]

Update:  Commenting that section out doesn't actually appear to fix it. Sorry, 
errant test result on my side.

However, commenting out the line

commandDownloader.add("-D"); // don't erase

in app/src/processing/app/debug/AvrdudeUploader.java *does* fix this issue.

Original comment by adamww...@gmail.com on 7 Jun 2010 at 10:52

[GoogleCodeExporter]

Erasing the entire chip is likely not a good idea either.

Anyway, it's starting to look like a mismatch between avrdude and the Arduino 
bootloader.  Avrdude skips telling the device about any pages consisting 
entirely of 0xFF, and assumes that any flash its writing to has been erased, 
while I suspect the Arduino bootloader doesn't do anything to pages it isn't 
told about.

Interestingly enough, this same issue occurs with the Optiboot bootloader.

Original comment by adamww...@gmail.com on 8 Jun 2010 at 5:44

[GoogleCodeExporter]

In theory, I would think that the -D option (don't do chip erase) that Arduino 
sends to avrdude should prevent this from happening.  if avrdude ahs not sent a 
chip erase command, it should not assume that the chip is erased.

Original comment by wes...@gmail.com on 5 Jun 2011 at 7:54

[GoogleCodeExporter]

This is particularly bad when using shields like the Gameduino. The Gameduino 
uses 0xf for a transparent pixel, so a few sprites that consist of small 
splashes of color surrounded by fields of transparency can lead to at least one 
page of 0xff. I'm presently struggling with this bug.

Original comment by Pika...@gmail.com on 9 Jan 2013 at 2:02