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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Kevin Cuzner-2
URL:
  <http://savannah.nongnu.org/bugs/?40061>

                 Summary: avrdude -U fails to save final FF bytes.
                 Project: AVR Downloader/UploaDEr
            Submitted by: bobc
            Submitted on: Wed 18 Sep 2013 05:50:04 PM GMT
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: BobC
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

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?





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?40061>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Kevin Cuzner-2
Follow-up Comment #1, bug #40061 (project avrdude):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?40061>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Kevin Cuzner-2
Follow-up Comment #2, bug #40061 (project avrdude):

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!".

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?40061>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Kevin Cuzner-2
Follow-up Comment #3, bug #40061 (project avrdude):

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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?40061>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Kevin Cuzner-2
Update of bug #40061 (project avrdude):

                  Status:                    None => Wont Fix              
             Open/Closed:                    Open => Closed                

    _______________________________________________________

Follow-up 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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?40061>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Kevin Cuzner-2
Follow-up Comment #5, bug #40061 (project avrdude):

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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?40061>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Joerg Wunsch
As Bob Cunningham wrote:

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

OK, so far about Bob.

I'd like to get opinions from others on this.

My ideas so far:

. The current behaviour has been intented as an optimization, and this
  certainly makes a lot of sense for the more common use cases
  (reading out memory to program it back later, or for some kind of
  eyeball review or disassembly).  So I don't like it to go away
  completely.

. Sure, I see Bob's point that sometimes, one might want to retain a
  full image of what has been there.

. I also see the point that with an application, followed by a
  bootloader very far away, basically the same considerations as above
  could be made to the intervening 0xFFs.  But where to draw the line?

One option for #2 were to have a separate indication that you really
want the full image, like -U flash:R:flashfile:i, where the capital
'R' indicates it.  That far, it should be simple to do.

As for #3, one idea I've got is to always consider full flash pages.
If a flash page turns out empty, omit it from the image.  That way, a
few bytes of 0xFF won't be dropped, but all large holes will.  (Such
holes are not only related to bootloaders, but could also happen if
there are separate application data.  The Xmegas even have their
"apptable" area for that purpose.)  But how to handle ancient AVRs
that don't have paged flash?  Impose some kind of artificial pagesize
just for that purpose?

Any other opinions?
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Simone
+1 for #2

-1 for #3, not usefull for me
Reply | Threaded
Open this post in threaded view
|

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

René Liebscher
In reply to this post by Joerg Wunsch
On 18.09.2013 21:53, Joerg Wunsch wrote:

> As Bob Cunningham wrote:
>
>> There is no reason to use a broken tool, nor to argue with folks who have
>> defended its decade of brokenness.
> OK, so far about Bob.
>
> I'd like to get opinions from others on this.
>
> My ideas so far:
>
> . The current behaviour has been intented as an optimization, and this
>    certainly makes a lot of sense for the more common use cases
>    (reading out memory to program it back later, or for some kind of
>    eyeball review or disassembly).  So I don't like it to go away
>    completely.
>
> . Sure, I see Bob's point that sometimes, one might want to retain a
>    full image of what has been there.
>
> . I also see the point that with an application, followed by a
>    bootloader very far away, basically the same considerations as above
>    could be made to the intervening 0xFFs.  But where to draw the line?
>
> One option for #2 were to have a separate indication that you really
> want the full image, like -U flash:R:flashfile:i, where the capital
> 'R' indicates it.  That far, it should be simple to do.
>
> As for #3, one idea I've got is to always consider full flash pages.
> If a flash page turns out empty, omit it from the image.  That way, a
> few bytes of 0xFF won't be dropped, but all large holes will.  (Such
> holes are not only related to bootloaders, but could also happen if
> there are separate application data.  The Xmegas even have their
> "apptable" area for that purpose.)  But how to handle ancient AVRs
> that don't have paged flash?  Impose some kind of artificial pagesize
> just for that purpose?
>
> Any other opinions?
One of Bob's points was "It is clear that avrdude and its images are
useless for verification, since they actively prevent all bytes from
being verified. "

I did not check this, but I always thought avrdude would verify the 0xFF
if the input files contain them. So the only point left is to read all
0xFF bytes from a device into the file, so they can be checked at later
programming.

#2 I think 'R' would be nice to have.

#3 Using pagesize sounds reasonable. And if someone uses an ancient avr
device that does not have pages, so he gets all the 0xFF bytes (page
size = memory size). I guess (newer) devices with larger memory, where
you save the most, will probably have all pages.


René

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Joerg Wunsch
As René Liebscher wrote:

> One of Bob's points was "It is clear that avrdude and its images are
> useless for verification, since they actively prevent all bytes from
> being verified. "
>
> I did not check this, but I always thought avrdude would verify the 0xFF
> if the input files contain them.

Yes, it does, albeit only version 6+ compares exactly those bytes that
are mentioned in the file.  Version < 6 did also assume all bytes not
mentioned in the file as 0xFF, and programmed and verified them.  This
was particularly annoying for bootloaders, where it went over all the
application area, too.

> #2 I think 'R' would be nice to have.

OK, Simone also voted for this.

> #3 Using pagesize sounds reasonable. And if someone uses an ancient avr
> device that does not have pages, so he gets all the 0xFF bytes (page
> size = memory size).

Good idea.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev