INTRODUCTION
The PIC16F87X family of microcontrollers has the ability
to write to their own program memory. This feature
allows a small bootloader program to receive and write
new firmware into memory. This application note
explains how this can be implemented and discusses
the features that may be desirable.
In its most simple form, the bootloader starts the user
code running, unless it finds that new firmware should
be downloaded. If there is new firmware to be downloaded,
it gets the data and writes it into program memory.
There are many variations and additional features
that can be added to improve reliability and simplify the
use of the bootloader, some of which are discussed in
this application note.
The general operation of a bootloader is discussed in
the OPERATION section. Appendix A contains assembly
code for a bootloader developed for the PIC16F877
and key aspects of this bootloader are described in the
IMPLEMENTATION section.
For the purpose of this application note, the term “boot
code” refers to the bootloader code that remains permanently
in the microcontroller and the term “user
code” refers to the user’s firmware written into FLASH
memory by the boot code.
FEATURES
The more common features a bootloader may have are
listed below:
• Code at the Reset location.
• Code elsewhere in a small area of memory.
• Checks to see if the user wants new user code to
be loaded.
• Starts execution of the user code if no new user
code is to be loaded.
• Receives new user code via a communication
channel if code is to be loaded.
• Programs the new user code into memory.
OPERATION
The boot code begins by checking to see if there is new
user code to be downloaded. If not, it starts running the
existing user code. If there is new user code to be
downloaded, the boot code receives and writes the
data into program memory. There are many ways that
this can be done, as well as many ways to ensure reliability
and ease of use.
Integrating User Code and Boot Code
The boot code almost always uses the Reset location
and some additional program memory. It is a simple
piece of code that does not need to use interrupts;
therefore, the user code can use the normal interrupt
vector at 0x0004. The boot code must avoid using the
interrupt vector, so it should have a program branch in
the address range 0x0000 to 0x0003.
The boot code must be programmed into memory
using conventional programming techniques, and the
configuration bits must be programmed at this time.
The boot code is unable to access the configuration
bits, since they are not mapped into the program memory
space. Setting the configuration bits is discussed in
the next section.
In order for the boot code to begin executing the user
code, it must know where the code starts. Since the
boot code starts at the Reset vector, the user code cannot
start at this location. There are two methods for
placing the starting point of the user code.
One method is to use an ORG directive to force the user
code to start at a known location, other than the Reset
vector. To start executing the user code, the boot code
must branch to this fixed location, and the user code
must always use this same location as its start address.
An alternative method is to start the user code at the
normal Reset vector and require that the user code has
a goto instruction in the first four instructions to avoid
the interrupt vector. These four instructions can then be
relocated by the boot code and programmed into the
area of program memory used by the boot code. This
simplifies the development of code for use with the
bootloader, since the user code will run when programmed
directly into the chip without the boot code
present. The boot code must take care of paging and
banking so the normal Reset conditions apply before
executing the relocated code.