Go Down

Topic: problem porting new bootloader with avrdude (Read 4 times) previous topic - next topic


It's been a while since I've been in the avrdude code but there was some code
at one point to try to avoid writing 0xff
It would look for a block of FFs and the remove it from the areas that need to be burned.
However it would still verify them.
It could be that the verify is what is taking all the time.

avrdude also has some really dumb sections in it with respect to reading data
depending on the interface used and the memory type accessed.
In some cases it will read blocks of 256 bytes but only use 1 byte from it. So reading
1k of data ends up reading 1000 256 bytes of data.
This is why the dragon is so slow dumping memory even though it is USB based.

Run it in verbose mode to see what is going on.
You will quickly see what it is doing.
Being able to make it better, well that is another matter.

But first you need to see what is really going on.

--- bill

Nick Gammon

ahh... those are great projects and worth checking out later but might not be what im after atm. right now my requirement is specifically for bootloader development... any help there would be greatly appreciated.

The solution I suggested can be used to program bootloaders. In the 2 minutes you say it takes avrdude to do its stuff you could copy the file to an SD card, and program it, much faster.

Getting another programmer may not help, if you are still using avrdude. There is a programming command to erase all flash (which takes a few microseconds) which is what my programming sketch does.


as mentioned in op and youve suggested again the programmer does not matter. its the same with "arduino as avrisp", real avrisp mkII, parallel port with giveio, ponyprog, usbasp, etc. i tried them all. sd card is not an option. contacts, not to mention my fingers, would surely wear out during the thousands of downloads it takes to debug exotic boot code (no exaggeration). its also unlikely any other utility could replace avrdude considering the feature set, many of which are not optional for my applications. i simply need to make the load high time for that 3 word test program as quick as loading the same one low. ie skip ff bytes instead of doing whatever it is doing with them now.

i think, bill, you are closer to the solution. unfortunately resources are not available to consider re-compiling avrdude even if i was competent enough to understand someone elses source. if i were set up to do windows programming i might be able to throw together my own version like i did for real mode os but thats not practical in this case either.

verbose mode reveals little. erase takes no time at all and the "writing flash" progress bar simply crawls along when loading that file. avrdude is known to be a flaky buggy oddball kludge but unfortunately the closest thing to a standard and apparently nothing better is available. guess ill just have to continue limping along watching that damn program take forever to do absolutely nothing. anyway thanks for the suggestions guys and i do appreciate the replies.


verbose mode reveals little. erase takes no time at all and the "writing flash" progress bar simply crawls along when loading that file.

"reveals little" ? Really? How many -v did you use?
My recommendation is to run with -v -v -v -v and save the output so you can see everything that is happening.
You will be able to quickly tell what is happening.
Try that and get back to us with what you see.

You should be able to tell how many blocks are being burned with what data
and then how much of the part is being read after the burn for verifying.
i.e. is it trying to burn the entire part, or it is trying to read back the full part for verifying or both?
or something else?

Once you know that you can start to look at options.
(much better than guessing)
For example,
There are options to erase the part before burning. It might be that is what enables the code that avoids burning FFs.
(I can't remember how that part of the avrdude code worked - sorry it's been quite a while since I went through the code)
Then there is the option to avoid verifying what was burned.


avrdude is known to be a flaky buggy oddball kludge

I think that is a bit harsh. I'll agree that it isn't very user friendly but
when things are hooked up correctly and the proper options are used it is quite reliable.

I don't think it is time to throw in the towel just yet.

--- bill


I went and took a look at the avrdude code.
It's starting to come back to me.
avrdude internally doesn't support multiple memory regions in the flash.
It tries to optimize the burn but it does it in a way that will
stop the burn when it reaches the highest address.

From my quick review it appears that your
example would be  the worst case situation. The burn starts from the lowest
address and continues to the highest address and you end up burning and verifying all the bytes in between
with 0xff - which essentially just wastes time.

I seem to recall being involved with a discussion about this several years ago
over on the avfreaks site.
I remember there was some debate about adding in code to skip over a page being burned
if the contents are 0xff (which they are in the internal buffers for on empty regions of the flash).
But I seem to recall there was no final resolution.

If you run avrdude in really verbose mode, you will immediately be able to tell
if this is what is happening.

Another thing to keep in mind is that usbasp devices are not particularly very fast.
I think they are running at USB 1.x speeds plus the AVR is running its heart out just trying
to manage the USB. There simply isn't many cycles left over to run the ISP interface
for the burn.

Something like a Teensy board running as an ISP programmer would be much faster
because it has native USB support.

--- bill

Go Up