Open GoogleCodeExporter opened 8 years ago
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
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
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
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
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
Original issue reported on code.google.com by
xyzz...@gmail.com
on 10 Feb 2012 at 1:58Attachments: