Now its time to send the application code to the bootloader, that's been programmed into an ATmega32A controller. It has to be sent in hex format, but I have no idea of "How to send it?"

The hex file compiled for an application code from atmel studio is as follows:


As per the standard the first line has data 0C942A000C943F000C943F000C943F00 and checksum 89. Do I have to just send the 16 bytes of data followed by checksum? In some programs, some lines don't even have 16 bytes of data. It only has 10 bytes with checksum at the end, eg: :0A0B4000CDBFED010895F894FFCF3A.

There is no clear examples anywhere. I expect someone out there must have some experience in it to help me.

  • \$\begingroup\$ You may want to swap this to embedded.SE \$\endgroup\$
    – Dzarda
    May 30, 2014 at 11:36
  • \$\begingroup\$ Hi Dzarda, Could you please elaborate \$\endgroup\$
    – gzix
    May 30, 2014 at 11:39
  • 3
    \$\begingroup\$ I don't have time to write a full answer at the moment but it's an Intel hex format and normally the easiest thing is to send the whole lot and decode in the bootloader. Then you can just use a regular terminal program to send it. \$\endgroup\$
    – PeterJ
    May 30, 2014 at 11:48
  • \$\begingroup\$ Hi PeterJ, I'm sure i can decode it. But do i have to include the checksum at each line end. And how to pad if some line got less data \$\endgroup\$
    – gzix
    May 30, 2014 at 12:00

3 Answers 3


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

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);
        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_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;

    while (response != RSP_FINISHED)
        response = process_line();
        if (response == RSP_OK)
        else if (response != RSP_FINISHED)
    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.

  • \$\begingroup\$ Hi PeterJ, when some pages other than last page have short-length code as in ":02072000FFCF09 :1007220041545E4950494E49543D220000000000A8", i am getting that 2 bytes shifting in every page till the end \$\endgroup\$
    – gzix
    Jun 10, 2014 at 13:12
  • \$\begingroup\$ @user2943851, I probably won't have a chance today but did you want to post the file in say pastebin and reply here with a link and I'll check it out and see what I can spot. \$\endgroup\$
    – PeterJ
    Jun 11, 2014 at 3:20
  • \$\begingroup\$ Right now, I am using SRecord to convert variable-length Intel Hex to Fixed-length Intel Hex. Though, It would be nice to learn the parsing of original Intel hex format. So trying hard \$\endgroup\$
    – gzix
    Jun 12, 2014 at 9:56

Regarding the HEX format:

As suggested in the comment, have a read about the Intel HEX format. http://en.wikipedia.org/wiki/Intel_HEX

What it says is basically, that each line corresponds to a block of data. The format of the line being as follows:



  • X is 1 byte specifying the payload length
  • Y is 1 byte specifying the payload type *
  • Z is the payload of length X bytes
  • C is 1 byte of the line's checksum


’00’ Data Record
’01’ End of File Record
’02’ Extended Segment Address
’03’ Start Segment Address Record
’04’ Extended Linear Address Record
’05’ Start Linear Address Record

See http://microsym.com/editor/assets/intelhex.pdf for the entire specification.

About the method of transmission:

It is also mentioned in the comment - You are much better off sending the entire file as-is. That way you don't need a specialized program at the PC-side, just a terminal that talks to your device. Then parse the text on-chip.

How to write it:

The easiest method is to start reading Atmel's application notes:

All Self-programming operations are performed using the SPM instruction

This can be found here: http://www.atmel.com/images/doc1644.pdf

The AVR109 is a famous bootloader for Mega devices. You may find lots of info here.

  • \$\begingroup\$ Ya i will parse and i will take only the data. My question now is "How to write it?", What to do with the checksum \$\endgroup\$
    – gzix
    May 30, 2014 at 12:32
  • \$\begingroup\$ Hold on, Ill edit the answer. \$\endgroup\$
    – Dzarda
    May 30, 2014 at 12:43

There are tools for such things. First and foremost: You don't really want to let the controller figure out where to put what, since that would require parsing the file on the controller.

Instead, convert the file to a binary file (which can be written 1:1 to flash), then let the controller flash it to the application address (you need to figure that out before). A possible program I see: Your application is linked to address 0x0 - this means that if the bootloader is at that specific address, it will not work (you will need to link it to some different address). If the bootloader resides at some other address (preferably at the end of the flash) you're good to go.

Please find a script which converts to binary and does everything else here: http://1drv.ms/1hj9eU0

It's intended for another Atmel family (AVR32) but you should get the idea. If you have questions, let me know.

  • \$\begingroup\$ I can't get what u mean by 1:1 to flash? \$\endgroup\$
    – gzix
    May 31, 2014 at 6:19
  • 1
    \$\begingroup\$ When you transmit that file to your device, you will not need to write ascii chars 'C' and '9' to your device but you will need to write the byte 0xc9 to that memory location. To create such a binary from a hex file, you will need to convert the hex to a "pure" binary file (this is what srec_cat from the zip file does). \$\endgroup\$
    – Tom L.
    May 31, 2014 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.