A FLASH Bootloader for PIC16 and PIC18 Devices.pdf
(
812 KB
)
Pobierz
AN851
A FLASH Bootloader for PIC16 and PIC18 Devices
FIGURE 1:
BOOTLOADER FUNCTIONAL
BLOCK DIAGRAM
Author:
Ross M. Fosler and
Rodger Richey
Microchip Technology Inc.
Bootloader
Firmware
RX
TX
INTRODUCTION
Transmit/Receive
Engine
USART
Among the many features built into Microchip’s
Enhanced FLASH Microcontroller devices is the capa-
bility of the program memory to self-program. This very
useful feature has been deliberately included to give
the user the ability to perform bootloading operations.
Devices like the PIC18F452 are designed with a desig-
nated “boot block”, a small section of protectable pro-
gram memory allocated specifically for bootload
firmware.
This application note demonstrates a very powerful
bootloader implementation for the PIC16F87XA and
PIC18F families of microcontrollers. The coding for the
two device families is slightly different; however, the
functionality is essentially the same. The goals of this
implementation stress a maximum performance and
functionality, while requiring a minimum of code space.
RAM
Buffer
FLASH
Program
Memory
Control
Command
Interpreter
EE
Data
Memory
Configuration
Registers
COMMUNICATIONS
FIRMWARE
The microcontroller’s USART module is used to
receive and transmit data; it is configured as a UART to
be compatible with RS-232 communications. The
device can be set up in an application to bootload from
a computer through its standard serial interface. The
following communications settings are used:
• 8 data bits
•No par ty
•1 STOP b t
The baud rate setting is variable depending on the
application. Baud rate selection is discussed later.
Basic Operation
Figure 1 summarizes the essential firmware design of
the bootloader. Data is received through the USART
module, configured in Asynchronous mode for compat-
ibility with RS-232 and passed through the
transmit/receive engine. The engine filters and parses
the data, storing the information into a data buffer in
RAM. The command interpreter evaluates the com-
mand information within the buffer to determine what
should be done (i.e., Is the data written into a memory
unit? Is data read from a memory unit? Does the firm-
ware version need to be read?). Once the operation is
performed, data is passed back to the transmit/receive
engine to be transmitted back to the source, closing the
software flow control loop.
2002 Microchip Technology Inc.
DS00851B-page 1
AN851
THE RECEIVE/TRANSMIT BUFFER
Memory Organization
All data is moved through a buffer (referred to as the
Receive/Transmit Buffer). The buffer is a maximum of
255 bytes deep. This is the maximum packet length
supported by the protocol. However, some devices
may not support the largest packet size due to memory
limitations. Figure 2 shows an example of the mapping
of the buffer within the PIC18F452.
PROGRAM MEMORY USAGE
Currently, PIC18F devices reserve the first 512 bytes of
Program Memory as the boot block. Future devices
may expand this, depending on application require-
ments for these devices. However, this bootloader is
designed to occupy the current designated boot block
of 512 bytes (or 256 words) of memory. Figure 3 shows
a memory map of the PIC18F452. The boot area can
be code protected to prevent accidental overwriting of
the boot program.
Note:
The actual packet length supported by a
particular device depends on the size of its
data memory.
A useful feature of the receive/transmit buffer is that it
retains its memory between packets, thus allowing very
fast repeat and replication operations. That is, if an
empty packet is sent, the data currently in memory will
be executed as if it were just received.
FIGURE 3:
PROGRAM MEMORY MAP OF
THE PIC18F452
FIGURE 2:
DATA MEMORY USAGE ON
THE PIC18F452
Boot Program
000h
Bootloader
Work Area
RESET Vector
0200h
008h
High Priority Interrupt Vector
0208h
Low Priority Interrupt Vector
0218h
Receive/Transmit
Buffer
107h
Program Memory
Unused
SFRs
FFFh
7FFFh
COMMAND INTERPRETER
Note:
Memory areas not shown to scale.
The command interpreter decodes and executes ten
different commands, seven base commands and three
special commands. A complete list of the commands is
provided in Appendix A. The base commands allow for
read, write, and erase operations on all types of
non-volatile memory. The other three commands are for
special operations, such as repeating the last
command, replicating the data, and resetting the device.
Note that the PIC18F devices have greater access to,
and control of, memory than PIC16F devices. For
example, PIC16F devices do not have access to the
configuration memory, thus they do not use the config-
uration commands. Therefore, not all instructions are
available in the PIC16F bootloader.
PIC16F87XA enhanced microcontrollers are designed
to use the first 256 words of program memory. Figure 4
shows the memory map of the PIC16F877A. Like the
PIC18F452 and other PIC18F devices, the boot area
can be write protected to prevent accidental overwriting
of the boot program.
DS00851B-page 2
2002 Microchip Technology Inc.
AN851
FIGURE 4:
PROGRAM MEMORY MAP OF
THE PIC16F877A
FIGURE 5:
DATA MEMORY MAP
000h
EE Data
Boot Program
Memory
RESET Vector
0100h
Boot Control Byte
XXXh
Interrupt Vector
0104h
Communication Protocol
The bootloader employs a basic communication
protocol that is robust, simple to use, and easy to
implement.
Program Memory
PACKET FORMAT
All data that is transmitted to or from the device follows
the basic packet format:
<STX><STX>[<DATA><DATA>...]<CHKSUM><ETX>
where each
<...>
represents a byte and
[...]
represents the data field.
The start of a packet is indicated by two ‘Start of TeXt’
control characters (
<STX>
), and is terminated by a sin-
gle ‘End of TeXt’ control character (
<ETX>)
. The last
byte before the
<ETX>
is always a checksum, which is
the two’s complement of the Least Significant Byte of
the sum of all data bytes.
The data field is limited to 255 data bytes. If more bytes
are received, then the packet is ignored until the next
<STX>
pair is received.
3FFFh
Note:
Memory areas not shown to scale.
REMAPPED VECTORS
Since the hardware RESET and interrupt vectors lie
within the boot area and cannot be edited if the block is
protected, they are remapped through software to the
nearest parallel location outside the boot block.
Remapping is simply a branch for interrupts, so PIC18F
users should note an additional latency of 2 instruction
cycles to handle interrupts. Upon RESET, there are
some boot condition checks, so the RESET latency is
an additional 10 instruction cycles (as seen in the
example source code).
For PIC16F87XA devices, the interrupt latency is an
additional 9 instruction cycles on top of the 3 to 4 nor-
mally experienced; the RESET latency is 18 instruction
cycles. This additional latency comes from saving
device context data in shared memory. The example
code uses locations 7Dh, 7Eh, and 7Fh to store the
PCLATH, STATUS, and W registers, respectively. The
source code can be changed, but the saved data must
remain in the shared memory area.
Note:
Although the protocol supports 255 bytes of
data, the specific device that contains the
bootloader firmware may have a sufficiently
large data memory to support the largest
packet size. Refer to the data sheet for the
particular device for more information.
CONTROL CHARACTERS
There are three control characters that have special
meaning. Two of them,
<STX>
and
<ETX>
, are intro-
duced above. The last character not shown is the ‘Data
Link Escape’,
<DLE>
. Table 1 provides a summary of
the three control characters.
DATA MEMORY USAGE
The last location in data memory of the device
(Figure 5) is reserved as a non-volatile Boot mode flag.
This location contains FFh by default, which indicates
Boot mode. Any other value in this location indicates
normal Execution mode.
TABLE 1:
CONTROL CHARACTERS
Control
Value
Description
0Fh
Start of TeXt
<STX>
04h
End of TeXt
<ETX>
05h
Data Link Escape
<DLE>
2002 Microchip Technology Inc.
DS00851B-page 3
AN851
Automatic Baud Rate Detection
The
<DLE>
is used to identify a value that could be
interpreted in the data field as a control character.
Within the data field, the bootloader will always accept
the byte following a
<DLE>
as data, and will always
send a
<DLE>
before any of the three control charac-
ters. For example, if a byte of value 0Fh is transmitted
as part of the data field, rather than as the
<STX>
con-
trol character, the
<DLE>
character is inserted before
the
<STX>
. This is called “byte stuffing”.
The bootloader is provided with an automatic baud rate
detection algorithm that will detect most baud rates for
most input clock frequencies (F
OSC
). The algorithm
determines the best value for the Baud Rate Generator
and then loads the SPBRG register on the
microcontroller with the determined value.
Note:
Refer to the specific device data sheet for
information about the USART module and
its associated registers.
Note:
Control characters are not considered data
and are not included in the checksum.
SYNCHRONIZING
COMMANDS
The first
<STX>
in the protocol is the synchronization
byte. It is used to match the device’s baud rate to the
source’s baud rate. Thus, the device is synchronized to
the source on every new packet.
The data field for each packet contains one command
and its associated data. The commands are detailed in
Appendix A.
COMMAND RESPONSE LATENCY
Note:
If a ‘Start of TeXt’ condition is received
during the reception of a packet, then no
synchronization occurs.
Flow control is built into the protocol. Thus, for every
received command (except RESET), there is a
response. If there is no response, then one (or more) of
the following has happened:
• the data was corrupted (bad checksum)
• the packet was never received
• the data field was too long
• RESET was executed
So how long do you wait before deciding a problem has
occurred? The response latency (shown in Figure 6) is
dependent on the amount of data sent, the command
being executed, and the clock frequency.
For read commands, the latency is highly dependent
on the clock frequency, and the size of the packet. For
a small packet at high frequency, the response is
almost immediate, typically on the order of a few micro-
seconds. For large packets, the latency could be on the
order of hundreds of microseconds.
In general, read commands require very little time com-
pared to write commands. Write commands are mostly
dependent on internally timed write cycles. For exam-
ple, the typical write time required for a single
EEPROM location is 4 ms. If the maximum packet size
(250 bytes of writable data) was sent, the receive to
transmit latency would be about 1 second.
SELECTING F
OSC
AND BAUD RATE
The recommended baud rate for this application is
9600 bps. This is the ideal rate for a device operating
from 4 MHz, to the device’s maximum operating fre-
quency (40 MHz in most cases). Higher baud rates are
possible, but degenerate conditions can occur.
There are a few clock frequency/standard baud rate
combinations that lead to a degenerate baud rate
selection during synchronization; under such condi-
tions, the device will never synchronize to the source.
Clock frequencies that avoid such degenerate
conditions are given by the equation:
F
OSC
= (1 ±
E
)(
X
+ 1)(16)(
B
)
where
E
is the error (typically 2%),
X
is the value for the
SPBRG register, and
B
is the baud rate. A table of cal-
culated clock oscillator ranges for most of the common
baud rates is provided in Appendix B for quick
reference.
BOOTING A DEVICE
Entering and Leaving Boot Mode
With the bootloader firmware loaded, there are two dis-
tinct modes of operation:
Boot Mode
and
User Mode
.
The bootloader uses the last location of data memory
to determine which mode to run in. A value of FFh indi-
cates Boot mode. Any other value indicates User
mode. Thus, a new part with its data memory not
initialized will automatically enter Boot mode the first
time.
FIGURE 6:
RECEIVE TO TRANSMIT
LATENCY
RX
TX
Delay
DS00851B-page 4
2002 Microchip Technology Inc.
AN851
Reading/Writing Data Memory
To leave Boot mode, the last location must be changed
to some value other than FFh. Then, a device RESET
(hardware or software) is initiated. For PIC18F devices,
the
RESET
command actually gener
ates a
true RESET
via the
RESET
inst
ruction
(same as MCLR). Other than
tying a port pin to MCLR, a true RESET is not possible
in firmware on PIC16F87XA devices. Although the
RESET
command is supported, it only causes the
PIC16F device to jump to the RESET vector; the regis-
ters used to perform bootload operations are not
changed to their RESET states.
Data memory is read or written one byte at a time,
through commands 4 and 5. Since it is not actually
mapped to the normal FLASH memory space, the
address starts at 000h and continues to the end of
EEDATA memory.
Note that the last location of the data memory is used
as a boot flag. Writing anything other than FFh to the
last location indicates normal code execution.
Configuration Bits
Reading/Writing/Erasing Program
Memory
PIC18F
PIC18F devices allow access to the device configura-
tion bits (addresses starting at 300000h) during normal
operation. In the bootloader, commands 6 and 7 pro-
vide this access. Data is read one byte at a time and,
unlike program memory, is written one byte at a time.
Since configuration bits are automatically erased
before being written, there is no erase command for
configuration memory.
Having access to configuration settings is very power-
ful; it is also potentially very dangerous. For example,
assume that the system is designed to run in HS mode,
with a 20 MHz crystal. If the bootloader changes the
oscillator setting to LP mode, the system will cease to
function — including the bootloader! Basically, the
system has been killed by improperly changing one bit.
It is also important to note some configuration bits are
single direction bits in Normal mode; they can only be
changed to one state, and cannot be changed back.
The code protection bits in Configuration Registers 5L
and 5H are a good example. If any type of code protec-
tion is enabled for a block, it cannot be disabled without
a device programmer. Essentially, the bootloader
cannot reverse code protection.
PIC18F
For the PIC18F devices, commands 1 through 3 sup-
port operations to FLASH program memory. Read
operations occur at the byte level. Write operations are
performed on multiples of 8 bytes (one block). Erase
operations are performed on 64 bytes (one row).
When writing program memory on a PIC18F device,
the memory should be erased. The default operation is:
bits can only be cleared when written to. An erase oper-
ation is the only action that can be used to set bits in
program memory. Thus, if the bootloader protection
bits are not setup in the configuration bytes, operations
on memory from 000h to 1FFh could partially, or
completely disable the bootloader firmware.
User IDs (starting at address 200000h) are considered
to be part of program memory and are written and
erased like normal FLASH program memory. The
Device ID (addresses 3FFFFEh and 3FFFFFh) is also
considered program memory. While they can be
accessed, however, they are read only and cannot be
altered.
PIC16F
PIC16F
The PIC16F87XA devices support reading and writing
to program memory. Commands 1 and 2 support oper-
ations to FLASH program memory. Read operations
occur at the word level (2 bytes). Write operations are
performed on multiples of 4 words (8 bytes). Since
write operations are erase-before-write, the erase com-
mand is not supported. The bootloader area, from 000h
to 0FFh, should be write protected to prevent
overwriting itself.
Neither the User ID nor the Device ID locations are
accessible during normal operation on the PIC16 archi-
tecture; therefore, these areas can neither be read nor
written.
The configuration memory is not accessible during nor-
mal operation on the PIC16 architecture; therefore, this
area can neither be read nor written.
2002 Microchip Technology Inc.
DS00851B-page 5
Plik z chomika:
fred1144
Inne pliki z tego folderu:
Embedded Web Server (microcontroller with TCP-IP).pdf
(3483 KB)
00236a.pdf
(566 KB)
A FLASH Bootloader for PIC16 and PIC18 Devices.pdf
(812 KB)
00660.pdf
(1173 KB)
00526e.pdf
(656 KB)
Inne foldery tego chomika:
- Разные
! Осциллограф РАДИОПРОГИ РАСЧЁТЫ СПРАВОЧНИКИ
!avr test
!Измерения и константы
#Proiecte PIC
Zgłoś jeśli
naruszono regulamin