Reducing download time (for bootloader) with avrdude

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

I tried to find an answer to these question in the avrdude help and also here in the forum, but I could not figure it out (maybe I used the wrong search terms):

1) Is there a possibility to skip the programming of the unused areas with avrdude?

To be more concrete:
I have a bootloader, which only uses around 2KByte at the end of an 128KByte device. When I progam the bootloader, avrdude programms also the area starting from 0x0000. This seems to be unnecessary, since the real code starts at byte address 0x1F800.

I only want avrdude to program only the highest 2KByte.

The intel-hex file starts like this

:020000021000EC
:10F800000C9472FC0C947CFC0C947CFC0C942AFEF2
:10F810000C947CFC0C947CFC0C947CFC0C947CFC88

2) Is there a possibility to program a raw binary file at a given start address?

3) If there is no possibility for (1) or (2):
Is there another tool, which can do this?

Thanks for any hint...

In the beginning was the Word, and the Word was with God, and the Word was God.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bet Jorge could write a pc c program that would read the hex file line by line, and if it was full of FFs, dont dl it.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is a feature of avrdude.
You could patch avrdude if it worries you.

Alternatively, you could use stk500.exe, jtagice.exe, atprogram.exe, or whatever you are happiest with.

The initial programming of a bootloader is a one-off job. I agree that it is a little irritating, but probably less time than I would need to spend on patching and building avrdude.

I seem to remember trying to build avrdude.exe on Windoze a year or two ago. It required all sorts of unspecified installations.
Building on Linux is normally a straightforward package install and go.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wonder why bother if that is a one-time boot programming...

Anyway, ad 3:

    a) I do not have ASes installed but check the AS4.19 and there is an option to upload any part of any memory space. I do not remember exactly how to but for sure there was "memory section", "from address" and "byte count" GUI window to pick. b) Another idea would be to check if dude can read elfs. If so, you could include your own small section and mark it as loadable.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your comments and ideas.
I just checked out the download tool at http://www.kanda.com/avr-isp-sof....
Yes, for the Atmel programmers there are a lot of tools. But I think avrdude can handle more programmers than any other tool.

In the beginning was the Word, and the Word was with God, and the Word was God.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Programming Arduino bootloaders into ATmega328 or ATmega1280 (using stk500v1 protocol) only programs the actual memory used by the bootloader. Then (by default) it will verify the whole address space (from 0 to the end of the bootloader, anyway.)

More recent versions of avrdude are supposed to only verify the areas that were actually programmed, and I think I've seen that work.

It may depend on the protocol and chip.
It certainly depends on what the .hex file contains. I'm firmly of the opinion that if the .hex file contains pages of 0xFF, then the programmer should program pages of FF, even if it "thinks" they should already be FF because it might have done a chip-erase.
(There are separate bugs against the arduino avrdude/bootloader combination for "skipping" memory containing 0xFF; since the bootloader does NOT have a chip-erase equivalent.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> (There are separate bugs against the arduino avrdude/bootloader
> combination for "skipping" memory containing 0xFF; since the bootloader
> does NOT have a chip-erase equivalent.)

Well, the actual bug is that the Arduino bootloader *pretends* to
perform the chip erase when being asked to, but then eventually forgets
about its duties, and doesn't keep up to that promise.

Sure, a bootloader can never perform an actual chip erase, but it should
do what it can do about, this is either to erase all application pages
immediately (which would be its equivalent of a chip erase), *or* erase
all pages at some later point in time.

Anything else is simply asking for trouble. After a chip erase, the users
can rely on all (user) pages being 0xFF'ed, without any explicit need of
subsequently over-programming all pages with 0xFF.

Nevertheless, as already mentioned, recent AVRDUDE versions (including the
publically available 6.0rc1) keep track of their input file(s), and only
touch those areas that are mentioned in the file(s). "areas" here means
not exactly the contents of the files only, but rounded up/down to full
flash pages.

> Another idea would be to check if dude can read elfs.

AVRDUDE 6.0 (rc1) can read ELF files, provided it has been compiled with
a libelf in sight. This in particular requires the libelf header files being
present at ./configure time which on typical Linux distributions,
requires a prior installation of something like the libelf-devel package
that is not installed by default.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Nevertheless, as already mentioned, recent AVRDUDE versions (including the
> publically available 6.0rc1) keep track of their input file(s), and only
> touch those areas that are mentioned in the file(s).

I just released AVRDUDE 6.0.1.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
the actual bug is that the Arduino bootloader *pretends* to perform the chip erase when being asked to, but then eventually forgets about its duties, and doesn't keep up to that promise.

I'd buy this if avrdude didn't behave the same way even when given the "don't do a chip erase" switch...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> I'd buy this if avrdude didn't behave the same way even when given
> the "don't do a chip erase" switch...

Even then: programming 0xFF into flash is a no-op. It's an expensive
way of not changing any bit there, because NOR flash can only program
bits from ‘1’ to ‘0’.

Nevertheless, version 6.0 does it that way now, provided the 0xFFs are
present in the input file. For Xmegas, it now also supports page erase
instead of a chip erase (for Mega/Tiny, the ISP protocol doesn't offer
that feature).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jörg,

thank you very much for releasing the new avrdude. I just tried the latest version 6.0.1 on XP, downloaded from http://download.savannah.gnu.org...
That's exactly that, what I was looking for. This version exactly behaves like intended: downloading of the bootloader (2K) only takes a fraction of the time it needed before to program the whole chip (mainly with 0xFF).
So, now, our well-known avrdude mainly programs the areas, which were found in the file. It knows all popular programmers and all(?) AVR parts. Thanks for your effort.

skotti

In the beginning was the Word, and the Word was with God, and the Word was God.