#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.
60
October 2010