Need explanation on how to flash HEX files on ATmega32u4 via AVR109 protocol

I am not an electronic expert, so forgive me if I am misusing the terms in my question or if my question contains imprecisions and/or misinterpretation on how a Leonardo Board works. Corrections are of course welcome.

I am trying to write a very simple chip flasher that, given an HEX file, will be able to flash it on a Leonardo board, via its bootloader. I understand that the Arduino Leonardo uses an ATmega32u4 and that the bootlaoder uses the AVR109 protocol.

Based on this information, I have been able to write some code that flashes bytes on the board, but once flashed, the code does not work.

My code roughly looks like this:

1. Parse the (intel) HEX file into a representation of how the memory should look like on the chip (i.e. for each record I extract the memory address to write to, and the data in the record).
2. For each couple of bytes in this representation, I issue a set memory address instruction, followed by a write low byte, followed by a write high byte.
3. Every 256 bytes flashed this way, I issue a write page instruction.

I have an hard time finding what I do wrong, because I am not sure about any of these steps. Step #1 produce data that looks OK (as one can see some familiar strings here and there):

...however, if I compare my data with the same HEX file flashed by AVRdude and loaded again from the chip, the two are widely different.

Step #2 works (the bootloader responds with a 0xD byte at each command, but I don't know if I am doing the right thing by flashing the low byte before the high one.

Step #3 also seem to work fine, but I am uncertain on whether memory pages are effectively 256 bytes large (I derived this figure from the chip's datasheet, table 28-11).

I will be extremely grateful to anybody who could review my "algorithm" and provide feedback on what I do right or wrong, and where are common source of errors in this kind of application.

• Just to clarify, is the image a dump of the ATmega memory after you write with your program? You say that the data loaded by AVRdude is different. Could you post an image of what gets loaded by AVRdude as well? Have you looked at the AVRdude source and compared it to yours to see what is being done differently? – embedded.kyle Sep 10 '12 at 13:12
• @embedded.kyle I need to get back home to post/test stuff... for now thanks! I will update the question in a few hours. :) – mac Sep 10 '12 at 14:30
• Since AVRdude is open source, studying what it is doing could be a path to resolving your questions. – Chris Stratton Sep 6 '13 at 17:38
• When I needed upload via USB (I suppose you need 32u4 over USB too) I tried to program AT90USBxxxx via AVR109 bootloader over USB. But I found it's was buggy and unreliable hence I've been using standard Stk500 over USB with latest LUFA library and I'm satisfied. I dislike AVR109 (and one almost identical protocol for even older devices). – TMa Mar 5 '14 at 23:20

I have been using dfu-programmer successfully on Linux (using a "bare-bone" atmega32u2/atmega32u4) from the command line. So it's very easy to integrate it in a Makefile.

A quote from that web site:

dfu-programmer-0.6.2.tar.gz contains the source tree for this project. Download this to build and install on a Linux/Unix/Mac system.

So you should be able to build it on a Mac. Or you can have a look in the source code.

The AVR109 documentation isn't very clear, but between the AVR109 documentation and the avrdude source code, I wrote up some simple java code (using jssc for serial) to write to the flash on AVR devices. The specific code for communicating with the device and reading the .hex file (not all features of .hex files are supported) is here. I haven't tested it thoroughly, but it did write and read back correctly on the device (BrainLink) I was using it with.

p.s. In regard to your specific points, AVR109 needs the high-byte first always (both for addresses and for block sizes). Also, the address is in words, not bytes, so the byte-address needs to be divided by two. And before any flash writing, you need to erase the flash.

• Had to update the code: I forgot that one needs to erase the flash first. – Alexander Pruss Aug 29 '14 at 5:01

If you are making a chip flasher just for programming, you should stop working on it right now. Atmel provides a utility called FLIP. It flashes Hex files on to the chips for you from straight usb granted the chip supports on-chip usb, such as the ATmega##U# family.

You can write w/e program you want in Atmel Studio, save the hex, open Atmel FlIP and flash the hex.

FLIP

• Oh wow this is an old question! – Funkyguy Sep 6 '13 at 17:28
• While FLIP seems to support Linux, an OSX version doesn't seem to be offered, so portability would be a strike against it, especially when it seems the poster already has the more portable AVRdude working... – Chris Stratton Sep 6 '13 at 17:37
• If anybody is doing microcontroller programming (or any other kind for that matter) on OSX, they will almost always have a linux or windows partition on the same computer. If not, they are doing it wrong. – Funkyguy Sep 6 '13 at 17:48
• I was under the impression iOS can only be programmed from OSX, so I don't know about "or any other kind"... – Stephen Collings Sep 6 '13 at 17:50
• Oh well I'm sure you can write iOS stuff on linux. I'm not sure about windows. I tried a while back to get started but I remember encountering trouble on windows. Linux is kind of the "programmers heaven" for general programming. – Funkyguy Sep 6 '13 at 17:52