avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: René Liebscher
Subject: Re: [avrdude-dev] [bug #40061] avrdude -U fails to save final FF bytes.
Date: Wed, 18 Sep 2013 23:48:22 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8

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é



reply via email to

[Prev in Thread] Current Thread [Next in Thread]