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

arduinoatmegaatmelavrflash

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:

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).
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.
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):

enter image description here

…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.

Best Answer

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.

Related Solutions

Electronic – AVR- sending application program to bootloader

This will need some further work on your part to integrate into your code but should give you some ideas. The first step in bootloader will be to include headers related to programming of the FLASH:

#include <avr/boot.h>
#include <avr/pgmspace.h>

A few other defines that help define things later and define some response codes at the end of processing each line are:

#define HEX2DEC(x)  (((x < 'A') ? ((x) - 48) : ((x) - 55)))
#define SPM_PAGEMASK ((uint32_t) ~(SPM_PAGESIZE - 1))
enum response_t {RSP_OK, RSP_CHECKSUM_FAIL, RSP_INVALID, RSP_FINISHED};

Then a routine like the following can be used to process the Intel hex format and write to FLASH. It is written for a larger device so handles extended addresses in the hex files so you can remove that for your smaller device to reduce the code size but it won't do any harm to leave in place. You'll also need to add your own UART receive / init code and determine what to do if things time out, I used a watchdog timer in this case.

enum response_t process_line()
{
    char c, line_buffer[128], data_buffer[64];
    uint8_t line_len = 0, data_len = 0, data_count, line_type, line_pos, data;
    uint8_t addrh, addrl, checksum, recv_checksum;
    uint16_t addr, extended_addr = 0, i;
    static uint32_t full_addr, last_addr = 0xFFFFFFFF;

    c = uart_getc();
    while (c != '\r')
    {
        if (c == ':')
            line_len = 0;
        else if (c == '\n')
            ;
        else if (c == '\0')
            ;
        else if (line_len < sizeof(line_buffer))
            line_buffer[line_len++] = c;
        c = uart_getc();
    }
    if (line_len < 2)
        return RSP_INVALID;
    data_count = (HEX2DEC(line_buffer[0]) << 4) + HEX2DEC(line_buffer[1]);
    if (line_len != data_count * 2 + 10)
        return RSP_INVALID;
    addrh =  (HEX2DEC(line_buffer[2]) << 4) + HEX2DEC(line_buffer[3]);
    addrl =  (HEX2DEC(line_buffer[4]) << 4) + HEX2DEC(line_buffer[5]);
    addr = (addrh << 8) + addrl;
    line_type = (HEX2DEC(line_buffer[6]) << 4) + HEX2DEC(line_buffer[7]);
    line_pos = 8;
    checksum = data_count + addrh + addrl + line_type;
    for (i=0; i < data_count; i++)
    {
        data = (HEX2DEC(line_buffer[line_pos]) << 4) + HEX2DEC(line_buffer[line_pos + 1]);
        line_pos += 2;
        data_buffer[data_len++] = data;
        checksum += data;
    }
    checksum = 0xFF - checksum + 1;
    recv_checksum = (HEX2DEC(line_buffer[line_pos]) << 4) + HEX2DEC(line_buffer[line_pos + 1]);
    if (checksum != recv_checksum)
        return RSP_CHECKSUM_FAIL;
    if (line_type == 1)
    {
        if (last_addr != 0xFFFFFFFF)
        {
            boot_page_write (last_addr & SPM_PAGEMASK);
            boot_spm_busy_wait();
        }
        return RSP_FINISHED;
    }
    else if ((line_type == 2) || (line_type == 4))
        extended_addr = (data_buffer[0] << 8) + data_buffer[1];
    else if (line_type == 0)
    {
        full_addr = ((uint32_t) extended_addr << 16) + addr;
        if ((full_addr & SPM_PAGEMASK) != (last_addr & SPM_PAGEMASK))
        {
            if (last_addr != 0xFFFFFFFF)
            {
                boot_page_write (last_addr & SPM_PAGEMASK);
                boot_spm_busy_wait();
            }
            boot_page_erase (full_addr);
            boot_spm_busy_wait ();
        }
        for (i=0; i < data_len; i+=2)
        {
            uint16_t w = data_buffer[i] + ((uint16_t) data_buffer[i + 1] << 8);
            boot_page_fill (full_addr + i, w);
        }
        last_addr = full_addr;
    }
    return RSP_OK;
}

It reads an entire hex line and verifies the checksum so check it against the Intel hex format to see how it works in detail before using. From there the general idea is that when it hits a new FLASH page boundary it does an erase but otherwise goes ahead and writes the data.

When the bootloader is entered this is the main code I was using to call it, but once again you'll need to work out what do to when a failure occurs. In my case I was using some custom PC software so sent back a few strings to indicate the status, but for a terminal upload you may just want to set an EEPROM flag depending on whether it was successful and you should boot to it or to show a human friendly message and call the bootloader again:

void enter_loader()
{
    enum response_t response = RSP_OK;

    uart_puts("+OK/\r\n");
    while (response != RSP_FINISHED)
    {
        response = process_line();
        if (response == RSP_OK)
            uart_puts("+OK/");
        else if (response != RSP_FINISHED)
            uart_puts("+FAIL/");
        wdt_reset();
    }   
    boot_rww_enable ();
    while (1) // Use watchdog to reboot
        ;
}

Anyway that should give you a good start and the above code has been pretty well tested with some fairly complex firmware. You'll just need a bit of work to write the missing UART and other initialisation code to determine when the bootloader should be called for your application. It may also need some tweaking for a ATmega32A but I think the approach should work pretty well across AVR devices.

Electronic – arduino – Datalogging on serial flash memory

First of all, the way flash works, in general, is that a write command can only change bits from one to zero. To return bits to one, you must erase an entire erase block. Therefore, you cannot just "write to it like a hard drive". On most flash devices, multiple writes can be made to the same block or even the same byte, again as long as you are only changing ones to zeros. (There are some flash devices where the manufacturer recommends against multiple writes to the same block, but this is rare.)

To answer your specific questions:

1) In general, the endurance is based on erase cycles on each block. You can write individual bits (to zero) as much as you want, but doing an erase to return bits to one will wear down those bits of flash.

2) One way is to use the first byte of each record as a status indicator. It starts, after erasure, as 0xFF. When you start writing the record, you write 0x7F to that byte (zero the high bit). Once you complete writing the record, you write 0x3F to that byte (zero the next highest bit). To mark a record as deleted, you write 0x00 to that byte. All of this takes advantage of the fact that you can always turn a bit from one to zero.

Later, when you're reading records, you only look at records with 0x3F in that byte. 0x7F means that the record writing was interrupted (power fail/reboot) and is invalid. Once an entire erase block has only 0x00, 0x7F and 0xFF blocks, it can be erased.

By the way, you can keep a map of used/free blocks in RAM so that you only have to scan when booting up.

3) See the top of this posting.

Best Answer

Related Solutions

Electronic – AVR- sending application program to bootloader

Electronic – arduino – Datalogging on serial flash memory

Related Topic