The last N bytes of an upload cannot be 0xFF

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the attached sketch.

What is the expected output? What do you see instead?
The LED should not turn on, but it does.

What version of the product are you using? On what operating system?
Arduino 0022 or 1.0, WinXP or Win7, Arduino Uno SMD edition or breadboarded 
ATmega328P, Optiboot loader from Arduino 1.0.

Please provide any additional information below.
Issue is evidently a combination of how AVRDUDE and optiboot work together. 
More detail is available on the Arduino forum:
http://arduino.cc/forum/index.php/topic,84243.0.html

Original issue reported on code.google.com by xyzz...@gmail.com on 10 Feb 2012 at 1:58

Attachments:

• uploadIssue.pde

[GoogleCodeExporter]

AVRDude apparently optimizes away uploading of 0xFF data, assuming that flash 
is already set to ones as a result of the "chip erase" command it sends early 
in the upload.  But the bootloader doesn't actually erase the chip OR ensure 
that unreceived data is initialized to 0xFF.  This was previously seen for full 
pages of 0xFF in the middle of data: 
http://code.google.com/p/arduino/issues/detail?id=273

I don't recall whether the workaround I suggested actually worked :-(

Original comment by wes...@gmail.com on 11 Feb 2012 at 2:11

[GoogleCodeExporter]

Smoking gun starts here: 
http://arduino.cc/forum/index.php/topic,84243.msg631588.html#msg631588

Original comment by wes...@gmail.com on 16 Feb 2012 at 5:10

[GoogleCodeExporter]

A newer version of AVRDude apparently changes the way that "unused" memory is 
handled, and will probably fix this issue.  
http://lists.nongnu.org/archive/html/avrdude-dev/2011-09/msg00015.html

Original comment by wes...@gmail.com on 10 Mar 2012 at 12:59

[GoogleCodeExporter]

The avrdude that came with Arduino 1.0 tells me that it's version 5.11, and the 
test sketch behaves the same under 1.0.

Original comment by xyzz...@gmail.com on 10 Mar 2012 at 1:50

[GoogleCodeExporter]

Wouldn't it be possible for optiboot to implement the "chip erase" command (by 
clearing each page manually?). Obviously this would decrease the expected life 
time and increase the programming time, but by making it optional, maybe people 
could decide whether or not they prefer protocol compatibility over increased 
lifetime.

Original comment by johnpatc...@googlemail.com on 25 Aug 2014 at 9:19