bugAVR Downloader/UploaDEr - Bugs: bug #40061, avrdude -U fails to save final FF...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #40061: avrdude -U fails to save final FF bytes.

Submitter:  Bob Cunningham <bobc>
Submitted:  Wed 18 Sep 2013 05:50:04 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Privacy:  Public
Assigned to:  None Originator Name:  BobC
Open/Closed:  Closed Release:  None
Programmer hardware:  Device type: 

Wed 18 Sep 2013 07:38:09 PM UTC, comment #5: 

No thanks, my work here is done.

It is clear that avrdude and its images are useless for verification, since they actively prevent all bytes from being verified.

There are other free tools available that get this simple thing right.

There is no reason to use a broken tool, nor to argue with folks who have defended its decade of brokenness.

Bob Cunningham <bobc>
Wed 18 Sep 2013 07:29:39 PM UTC, comment #4: 

No point in yelling, sorry.

This has been a deliberate decision made 10 years ago, see
SVN log for revision 331 of (e.g.) fileio.c.  See also the
respective discussions in the mailing lists:

http://lists.nongnu.org/archive/html/avrdude-dev/2003-05/msg00068.html
http://lists.nongnu.org/archive/html/avrdude-dev/2003-05/msg00061.html

If you want to debate this decision, please subscribe to the
developers mailinglist, and explain the relative merits of
the current version vs. the behaviour you'd like to see.
Then see what other users and developers think about it.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 18 Sep 2013 07:03:36 PM UTC, comment #3: 

It gets worse: I just checked the saved image, and found it contains almost 20K of FF bytes in the middle (bootloader at one end, app at the other).

Why does avrdude IGNORE the TWENTY THOUSAND FF bytes in the middle, and still take away the 18 FF bytes at the end?

Silly and broken.

Bob Cunningham <bobc>
Wed 18 Sep 2013 06:21:46 PM UTC, comment #2: 

This is a bug, since a verify of the full 32K would fail if the high bytes had been modified.

When I ask for a full image to be read, I expect every byte to be preserved.

It is silly, irresponsible and reckless to do otherwise.

If this foolish, pointless and dangerous "optimization" is to be retained, it should be controlled by a flag that defaults to "No!".

Bob Cunningham <bobc>
Wed 18 Sep 2013 06:12:49 PM UTC, comment #1: 

This is a feature: as writing NOR flash with 0xFF is a NOP,
the topmost cells are being considered to not contribute to
the actual contents, and are thus left off from the output
file.  So if you re-write the resulting file into an erased
device, you get the same as you had before.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 18 Sep 2013 05:50:04 PM UTC, original submission:  

I wanted to preserve the original content of a borrowed ATmega328p Arduino before overwriting it for non-Arduino use.  I used both the Atmel Studio utility and avrdude to obtain an image of the flash content.

Atmel Studio saved 32768 flash bytes to an Intel hex file.

"avrdude -p ATmega328p -c avrispmkII -P usb -U flash:r:flashSave.hex:i" saved 32750 flash bytes into an Intel hex file, 18 fewer bytes than Atmel Studio saved.

The actual text file sizes were very different because the two programs use different line lengths.  I used avr-objcopy to convert them to the same line length, then compared them using diff.

Comparison of the files showed that avrdude failed to save the highest 18 bytes of flash, all of which were FF.

Both files contained identical information up to that point.

I next tried "avrdude -p ATmega328p -c avrispmkII -P usb -t", and at the prompt entered "read flash 0 32768", and the upper 18 bytes were shown correctly.

So avrdude "read" is able to read the full flash content.  Then why does "-U" fail to save the last 18 "FF" bytes to the output hex file?

Bob Cunningham <bobc>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by bobc (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-18 joerg_wunsch StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code