Nuts and Volts - October 2010

#27

AVR Memory Part 5: Bootloaders

Follow along with this series! Joe’s book & kits are available at www.nutsvolts.com

by Joe Pardue

Recap

We discussed bootloaders a bit in Smiley’s Workshop 22 (Busy as a BeAVR), and learned about the debt they owe to Baron Munchhausen’s bootstraps. This month, we’ll get more practical and build on last month’s AVR Memory Part 4 – Writing to AVR Flash where we learned how AVR Flash memory is structured and how to write to it. We tested that knowledge with the SmileyFlash Writer.c program. This month, we will build on this to create our own bootloader. You’ll need access to last month’s source code in Workshop26.zip [ NutsVolts.com or SmileyMicros.com] to follow some of the instructions.

will use avrdude on a PC to communicate with the AVR bootloader via the USART. As we will see shortly, avrdude is a very versatile tool that can handle many different programming protocols. We will be using the AVR109 protocol in avrdude but we will implement only those commands necessary for uploading program memory. There are other tasks that could be implemented such as allowing us to read and write EEPROM, but since we want to keep this bootloader small and simple, we won’t add those functions.

EduBootAVR - A Bootloader Written in C

A bootloader is a program that is used to download other programs. It usually resides in a special part of memory and is invoked when the device comes out of reset. It responds to data being sent — usually over a serial port — from an external device. The bootloader and the external device use a communication protocol that allows them to conduct transactions that mostly involve sending pages of binary program code to be written to the device application program section. For our demonstration, we

■ FIGURE 1. STK-500 with ATmega644.

Deciding to Run the Bootloader or the Application

A bootloader is used to upload application programs. When you’ve uploaded an application, you then have two programs on your AVR: the application that begins at Flash memory location 0x0000 and your bootloader that begins at the NRWW (see last month) high memory location you’ve selected for the particular device (such as 0x3E00 for an ATmega328). Now, you have to decide which program you want to run when your AVR starts up. Generally, your system should be designed to run the application and only run the bootloader when you actually need it to upload some code. You could do this by having a function in your application that allows you to call the bootloader, but what if your application gets trashed? Then how will you upload your code? Atmel designed the AVR so that those with boot sections can have the device start up in that boot section if the BOOTRST fuse is set. With that fuse set, when the AVR starts after reset it loads the bootloader start address (also set by fuses) and starts the program from there.

The standard way to start up a microcontroller that is using a bootloader is to have the bootloader start and let it check for some indicator that it is needed. You could have the bootloader wait to see if an external programmer is trying to talk to it via the USART; after a brief pause with no attempt at contact, the bootloader can decide it isn’t needed and execute a jump to the application code at 0x0000. The downside of this technique is that you want the wait to be long enough to realistically allow a bootloader communication to begin, but not so long that a user might think something has gone wrong.