AN1310

High-Speed Serial Bootloader for PIC16 and PIC18 Devices

• PC software rewritten in C/C++ for the cross-
Author: E. Schlunder platform, QtSM SDK, enabling Linux host support
Microchip Technology Inc. by recompiling the PC software source code
• A simple, Serial Terminal Application mode,
provided by the PC software, that eliminates time
INTRODUCTION
wasted by switching between separate bootloader
Microchip’s enhanced Flash microcontrollers enable host and serial terminal applications
firmware to program itself. This is done by a “boot-
loader” providing a firmware kernel, residing in the Note: If a review of the preceding features list
microcontroller. The kernel uses a small portion of pro- indicates that a different bootloader is
gram memory not normally used by the firmware’s needed, see “Alternative References”.
main application.
When the bootloader firmware is activated, a host PC
Prerequisites
can use a serial protocol to read, write and verify Before using the serial bootloader, the following is
updates to the microcontroller's application firmware. required:
Once the application firmware is programmed, the
• Familiarity with Configuration bits, compiling and
bootloader cedes control, allowing normal application
programming PIC® microcontrollers
execution until the bootloader is called.
• A development board with a serial port connected
to the PIC device's USART1 RX/TX pins
AN1310 Bootloader Features
• A PC with a serial port or USB-to-serial adapter
The key features of the AN1310, “High-Speed Serial • A traditional programming tool for initially writing
Bootloader for PIC16 and PIC18 Devices” include: the bootloader firmware into the PIC device (such
• Small firmware code size (less than 450 instruction as REAL ICE™ emulator, PICkit™ 3 or MPLAB®
words on most devices) ICD 3)
• Automatic baud rate synchronization to the host • Installation of the MPLAB® IDE software
• Baud rate flexibility, from 1,200 bps to 3 Mbps for • Installation of the AN1310, high-speed serial
extremely fast programming bootloader software
• A 16-bit CRC packet and Flash memory The AN1310 high-speed serial bootloader software
verification for quick verification of successful package (including full source code) can be down-
programming, even at low baud rates loaded from the www.microchip.com/applicationnotes
• An advanced “write planner” that eliminates web site.
unnecessary erase/write transactions 1. When the Browse Application Notes page appears,
• Support for a wide variety of PIC16 and PIC18 go to the Select a Function menu and select
devices through an “essential device characteristics” “Bootloader” under “Programming & Bootloaders”.
database 2. Click the Search button.
• Optional application remapping that does not 3. Scroll down to AN1310 and click the compressed
require linker script modifications or remapping of file icon in the “Resource Type” column.
interrupt service routines
• A forced bootloader re-entry mechanism requiring
minimal start-up delay and no additional I/O pins or
application firmware code to re-enter the bootloader
• Optional MCLR Reset control, allowing the host
PC application to automatically reset the device
for robust bootloader re-entry

 2010 Microchip Technology Inc. DS01310A-page 1

AN1310
IMPLEMENTATION BASICS Step 1:
Compile and Program Bootloader
This section gives the three basic steps for setting up
and using the bootloader for those already familiar with Firmware
bootloader/application development. More detailed information on this step is provided in:
Subsequent sections provide overview and more • “Firmware Overview”
detailed information relating to these steps. Those
• “Hardware Considerations”
sections include:
• “Bootloader Mode Considerations”
• “Firmware Overview”
• “Software Design”
• “Hardware Considerations”
By default, the serial bootloader installation provides
• “Bootloader Mode Considerations”
bootloader firmware source code in the PC path:
• “Application Mode Considerations”
• “Software Design” C:\Microchip Solutions\Serial
Bootloader AN1310 vX.XX\PICxx Bootloader\

FIGURE 1: CONFIGURATION BITS DIALOG BOX

To compile and program the bootloader firmware: TABLE 1: CONFIGURATION BIT

1. Open the appropriate PIC16 or PIC18 bootloader SUGGESTIONS
project in the MPLAB IDE software. Category Setting
2. Select Configure>Select Device... and choose
the PIC device to be used (for example, Watchdog Timer(1) “Disabled”
PIC18F87J90). Extended Instruction
“Disabled”
3. To specify Configuration bit settings, select Set Enable bit
Configure>Configuration Bits.... (Select according to hardware.
Oscillator Selection
The dialog box, shown in Figure 1, appears. Higher speeds generally
bits
enable more baud rates.)
4. Specify settings for each category.
Fail-Safe Clock
Table 1 gives suggestions for selected bits that “Enabled”, if available
Monitor Enable bit
can get the bootloader initially working.
Low-Voltage
5. Compile and program the bootloader firmware “Disabled”, if applicable
Program (LVP)
into the microcontroller. Table Read-Protect “Disabled”, if applicable
The bootloader must be programmed into the Note 1: On most PIC devices, the Watchdog Timer
PIC device using an ICSP™ programming tool, can be re-enabled in application firmware
such as MPLAB® ICD 3 or a socketed program- after start-up.
mer like the MPLAB PM3 Universal Device
Programmer.

DS01310A-page 2  2010 Microchip Technology Inc.

 AN1310
Step 2: 3. Select values for the “COM Port” and
Connect Host to Bootloader “Bootloader Baud Rate” fields and click OK.
Using a moderate speed “Bootloader Baud
1. Open the serial bootloader host PC software
Rate”, such as 19.2 kbps, may help with initial
(AN1310ui.exe).
communications. Non-standard, high-speed
2. If this is the initial setup, configure the serial port baud rates can be attempted once everything is
and bootloader baud rate by selecting working.
Program>Settings.
The software allows serial communication with
The dialog box in Figure 2 appears. application firmware after programming. Appli-
cations can require a particular baud rate, so a
FIGURE 2: SETTINGS DIALOG BOX separate “Application Baud Rate” setting is pro-
vided. For the example application firmware
projects, the 115,200 bps rate is suggested.
4. Connect the PC's serial port to the PIC MCU
development board.
5. Go into “Bootloader” mode on the PC by clicking
the red bootloader software button, shown in
Figure 3, or pressing the PC’s <F4> key.
The PC software attempts to communicate with
the PIC bootloader firmware, using the specified
bootloader baud rate. If communications are
established, the PC displays the bootloader
firmware revision and the PIC device’s
information, as shown in Figure 3.

FIGURE 3: SERIAL BOOTLOADER HOST PC APPLICATION

“Bootloader Mode” Button

Bootloader Firmware Version

PIC® Device’s Information

Bootloader Baud Rate

 2010 Microchip Technology Inc. DS01310A-page 3

AN1310
Step 3: FIRMWARE OVERVIEW
Program Application Firmware
There are two modes of firmware operation: bootloader
More detailed information on this step is provided in: and application. When the microcontroller comes out of
Reset, the bootloader start-up routine decides whether
• “Application Mode Considerations”
to enter the bootloader command loop (Bootloader
• “Software Design” mode) or jump to the application entry point vector
Once the host PIC is connected to the bootloader, the (Application mode).
PIC device can be read, written, erased or verified. A With no intervention, the Bootloader mode is entered if
sample application firmware project is installed with the either of the following conditions apply. If these
software in the path: conditions do not apply, the Application mode is entered:
C:\Microchip Solutions\Serial • If application firmware code has not been pro-
Bootloader AN1310 vX.XX\PICxx Application\ grammed into the microcontroller, the Bootloader
mode is entered.
1. Open the appropriate project in the MPLAB IDE • If the PIC device’s RX pin is at logic level low (the
software, select the desired device, configure RS-232 “Break” state) when the microcontroller
the settings and compile the application comes out of Reset, Bootloader mode is entered.
firmware.
Bootloader mode also can be entered manually or
2. Open the resulting application firmware’s hex
automatically through software or hardware.
file with the host PC’s serial bootloader
software.
3. Write the application firmware into the PIC
Manual Break and Reset for Re-Entry
device by clicking the software button with the The host PC software enables the PIC device's RX pin
red down arrow or by pressing the PC’s <F6> to be put into the RS-232 “Break” state. This holds the
key. PIC device's RX pin low, forcing the microcontroller into
4. Direct the bootloader to start the application Bootloader mode when it is reset.
firmware by clicking the software’s green “Run To manually enter Bootloader mode:
Mode” button or pressing <F2> on the PC.
1. Click the software’s blue “Break/Reset Mode”
In this mode, the PC software acts as a simple button, shown in Figure 5, or press the PC’s
serial terminal application, as shown in Figure 4. <F3> key.
This allows two-way text communication with
the application firmware through the PIC
FIGURE 5: BREAK/RESET MODE
device's USART1 port.

FIGURE 4: APPLICATION RUN MODE

“Run Mode” Button

“Break/Reset Mode” Button

2. Reset the PIC device (so that the bootloader

start-up routine is executed) by doing one of the
following:
• On the development board, press the
MCLR Reset button, shown at right
• Disconnect and reconnect the power
The device resets and the bootloader start-up
routine notices the “Break” request on the RX
Status pin. Bootloader mode is entered, even if applica-
Application Baud Rate tion firmware has been programmed into the
device.
3. Connect to the bootloader on the PC by clicking
the software’s red “Bootloader Mode” button,
shown in Figure 6, or pressing the PC’s <F4>
key.

DS01310A-page 4  2010 Microchip Technology Inc.

 AN1310
FIGURE 6: “BOOTLOADER MODE” This code continuously monitors the USART module’s
BUTTON state for a framing error. When a framing error occurs,
the code verifies that the RXD pin is being held at a
logic low level, indicating that the host PC is most likely
transmitting an RS-232 Break state to request boot-
loader re-entry. The application responds by initiating a
“Bootloader Mode” Button software Reset of the microcontroller and passing
control to the bootloader start-up routine.

The PC software attempts to communicate with the PIC16 microcontrollers, however, have no software
bootloader using the bootload baud rate. If successful, Reset instruction, so the application jumps to the boot-
the PC receives the bootloader firmware revision and loader start-up vector at address, 0h. To avoid leaving
the PIC device information, shown earlier in Figure 4. unremovable return addresses on the call stack, jump-
ing to address 0h must be done only from the
application’s “main()” function.
Software Bootloader Re-Entry
The preceding procedure for manually executing the Hardware Bootloader Re-Entry
re-entry sequence can be cumbersome when making
many incremental application firmware changes during The software re-entry procedure is useful for getting
development. An easier alternative is to use the simple started, but is not recommended for robust operation.
software re-entry mechanism, given in the example Should the application code have bugs, the application
application firmware project. firmware could lock up and prevent automatic
bootloader re-entry for the next code change.
That mechanism is shown in Example 1.
Additionally, an actual framing error, triggered during
normal application serial communications, could
EXAMPLE 1: SOFTWARE BOOTLOADER
inadvertently cause unintended re-entry into Boot-
RE-ENTRY
loader mode. Then, the application could not be
while(1) restarted without user intervention.
{
if(PIR1bits.RCIF) For a more robust, hardware-based bootloader re-
{ entry, the serial port RTS signal can be wired to control
if(RCSTAbits.FERR && the PIC device’s MCLR Reset signal. This allows the
!PORTCbits.RC7) host PC software to automatically assert Break and
{ Reset signals, as described in “Manual Break and
// receiving BREAK Reset for Re-Entry”.
// state, soft reboot
// into Bootloader mode.
Reset();
}
}
(...)
}

 2010 Microchip Technology Inc. DS01310A-page 5

AN1310
HARDWARE CONSIDERATIONS If using a PIC device that requires high voltage (above
VDD) on MCLR to enter the In-Circuit Serial Program-
Figure 7 represents a typical connection diagram for ming™ (ICSP™) mode, the RTS/MCLR diode can
the serial bootloader. interfere with traditional ICSP programming/debug-
RTS-based MCLR Reset control is optional. When con- ging. In this case, using an N-channel metal oxide
nected, the host PC can use the RTS serial port signal semiconductor field effect transistor (MOSFET) may be
to pull down the PIC device’s MCLR pin, allowing the more appropriate. (See Figure 8.)
host PC software to automatically reset the device An RS-232 transceiver chip typically provides an inter-
when entering the Bootloader mode. nal pull-down resistor on the incoming TXD/RTS sig-
nals. This allows the PIC device to normally see logic
level high on its RX pin (the RS-232 “Idle” state) even
when disconnected at the serial port, DB9 connector.

FIGURE 7: RX PIN SCHEMATIC

+3.3V
+ U2
C3 1
0.1F C1+
2 0.1F
V+ C1
+3.3V
3
6 V- C1- +
4
C2+
0.1F C4
+3.3V

10 k
J1 C2 0.1F
+

R1
1 5 U1
C2-
RXD 2 6 11
GND R3 VDD
TXD 3 7 RTS 13 1
MCLR#
4 8 D1
470 
5 9 C5 0.1F
8 R2
26 RC7/RX
DB9
470 
GND

11 25
RC6/TX

10

12
V SS
MAX3232 GND ®
PIC Device

FIGURE 8: MOSFET SCHEMATIC

+3.3V
+ U2
1
0.1F C3 C1+
2 0.1F
V+ C1
+5V
3
6 V- C1- +
4
C2+
0.1F C4
0.1F +5V
10 k

J1 C2
+
R1

1 5
C2- U1
RXD 2 6 11
GND VDD
TXD 3 7 RTS 13 1 MCLR#
4 8
5 9 C5 0.1F
8
R2
26 RC7/RX
DB9
470 
470 

GND
R2

11 25 RC6/TX

10
12
V SS
®
Q1 PIC Device
2N7002

DS01310A-page 6  2010 Microchip Technology Inc.

 AN1310
Entering Application Mode TABLE 2: EXAMPLE HIGH-SPEED,
USB-TO-SERIAL BAUD RATES
To ensure the device can reliably enter Application
mode, it is suggested that: PL2303 FT232BM
• The device be held in Reset long enough for the 6,000,000 3,000,000
RX pin to be pulled high, signifying the RS-232 3,000,000 2,000,000
“Idle” state
2,457,600 1,500,000
• Data not be transmitted to the microcontroller
during, and immediately after, the device has 1,228,800 1,411,765
come out of Reset 921,600 1,333,333
Incoming data could be misinterpreted as an 614,400 1,263,158
RS-232 “Break” state, causing the bootloader 460,800 1,200,000
start-up routine to enter Bootloader mode.
230,400 1,142,857
When using a custom RS-232 transceiver circuit, 1,000,000
ensure that the PIC device’s RX pin is pulled up to VDD
when Idle or disconnected from the host PC serial port. 750,000
If the PIC device’s RX pin is left floating or pulled down, 500,000
Bootloader mode could be erronenously entered. 250,000

High-Speed Baud Rates The PIC device also will have limited steps between
available baud rates, dependent on the FOSC clock
The bootloader is capable of operating at baud rates of source used and the PIC device’s baud rate formula
up to 3 Mbps. Reliably achieving high-speed baud (see Table 3).
rates requires some considerations in the hardware
design. TABLE 3: PIC® DEVICE BAUD RATE
Traditionally, PCs’ serial ports only operate at standard FORMULAS
baud rates of up to 115.2 kbps. Manufacturers of USB- BRG16 BRGH PIC Baud Rate
to-serial converters may claim higher baud rates, but
some incorporate level translator circuits that limit 0 1 FOSC/[16 (BRG + 1)]
performance to baud rates of 500 kbps or less. 1 1 FOSC/[4 (BRG + 1)]
More reliable, high-speed operation may be provided
The bootloader firmware source code automatically
by a bare logic level, USB-to-serial converter circuit
uses the BRG16 = 1, BRGH = 1 mode on microcon-
wired directly to the PIC device without RS-232 level
troller devices that support it. This is the most flexible
translators.
mode for hitting the widest range of possible baud
Another hardware design consideration is matching the rates.
PIC device's clock source frequency to the baud rates
To avoid miscommunication, the PIC device and serial
available on the host serial port. At high speeds, USB-
port baud rates ideally should match within 3%. If a
to-serial converters may have limited steps between
CRC error is detected during communications with the
available baud rates.
bootloader firmware, the host PC application will halt
As an example, some of the currently available baud and display an error status.
rates for two USB-to-serial converters are shown in
Table 2. (For more information, consult Prolific Tech-
nology Inc. (PL2303), Future Technology Devices
International Limited (FT232BM) or your converter’s
data sheet.)

 2010 Microchip Technology Inc. DS01310A-page 7

AN1310
Bootloader Firmware Operation PIPELINED READS
Figure 9 summarizes the essential operating design of This bootloader avoids using the RAM buffer during
the bootloader. device read operations, unlike the original bootloader
document in AN851.
Data is received through the USART module and
quickly stored to the RAM buffer to avoid overrun Data read from Flash/EEPROM is streamed directly to
errors. After each packet is received, the integrity of the the USART module. This has some key advantages:
data is verified using a 16-bit CRC. • The microcontroller RAM size no longer limits the
response packet size
FIGURE 9: BOOTLOADER • An entire device memory range can be read with
FUNCTIONAL BLOCK a single request transaction, minimizing
DIAGRAM transaction overhead
• The processor core and the USART can operate
Bootloader in parallel (pipelining), reducing total clock time
RX TX Firmware
USART COMMUNICATIONS
The microcontroller's USART module is used to receive
Transmit/ and transmit data. The communications settings are:
USART Receive
Engine • Eight data bits
• No parity
• One Start/Stop bit
RAM • Variable baud rate
Buffer
An auto-baud routine is used to measure the bit rate of
the initial Start-of-Text character (STX or 0Fh). Unlike
Flash Program the original bootloader, the auto-baud routine is not run
Data Bus

Memory
at the beginning of every packet. Once the baud rate is
successfully captured, it is locked in until the
EE Data Command
Interpreter bootloader command loop receives an invalid or
Memory
unexpected request.
Configuration Locking the baud rate allows high baud rate data to be
Registers received without losing data during slow auto-baud
Control calculations. When an invalid or unexpected request is
received, the auto-baud routine is run again.
When a valid request packet has been received, the When switching between baud rates, the bootloader
command interpreter evaluates the command number firmware can get locked at the wrong baud rate and the
in the packet to determine what operation needs to be incoming data stream may not trigger the auto-baud
done (such as Erase, Write, Read or Verify). The routine to be run again. In such situations, a MCLR
request is fulfilled and a response is returned through Reset is required to force the auto-baud routine to run.
the USART to either Acknowledge completion of the When RTS is wired to control MCLR, such situations
task, or on Read operations, to send back device can be handled automatically by the host PC
memory data. application asserting a MCLR Reset.
The host PC application is not allowed to send more
than one packet at a time. Each packet must be
Acknowledged before the next can be sent. This
maintains flow control.
For detailed bootloader protocol documentation, see
Appendix A: “Bootloader Protocol” on page 19.

DS01310A-page 8  2010 Microchip Technology Inc.

 AN1310
BOOTLOADER MODE Example 2 shows a PIC16 far GOTO code sequence
that will be recognized as a valid application Reset
CONSIDERATIONS
vector by the software.
In the default configuration, bootloader firmware is EXAMPLE 2: PIC16 RESET VECTOR
stored at the end of Flash program memory space.
ORG 0
Keeping the bootloader at the end of program memory
ResetVector:
space allows application firmware to handle interrupts movlw high(FarApplication)
at the normal hardware interrupt vector address. This movwf PCLATH
configuration keeps interrupt latency to a minimum. goto FarApplication
The host PC bootloader application will write a “GOTO”
as the first instruction at the Reset vector (address, (...)
0000h). This GOTO jumps to the bootloader at start-up.
FarApplication:
The application firmware’s original Reset vector (...)
instruction is automatically moved to reside just before
the bootloader block of memory. The bootloader firm-
ware uses this application Reset vector to start the Incremental Bootloading
application when the Bootloader mode is not requested After the PIC device has been programmed, the host
(see Figure 10). PC application continues to monitor the hex file on the
On PIC18 devices, this automatic relocation of the disk. If the application firmware is modified and
Reset vector requires the application firmware to recompiled, the host PC bootloader application will
provide a single GOTO instruction as the first instruction immediately notice the change. This triggers the host
at address, 0000h. PC application to do an incremental update of the
device’s firmware.
FIGURE 10: PROGRAM MEMORY Incremental updates compare the last programmed
hex file and the new file to determine which bytes of
0000 h program memory to change. Only memory blocks with
Bootloader Reset Vector
0008 h changes are reprogrammed. When developing large
High Priority Interrupt Vector application projects, this can save significant time and
0018 h
Low Priority Interrupt Vector increase productivity.

Write Protection
To ensure that bootloader firmware is always available
for updating the device, it is wise to write-protect the
Application Firmware bootloader’s block of Flash memory space (the boot
block). This can be accomplished through software or
hardware.

SOFTWARE WRITE PROTECTION

Software-based boot block write protection is enabled
Application Reset Vector
by the USE_SOFTBOOTWP option in the file,
bootconfig.inc. With this feature turned on, the
Bootloader Firmware bootloader firmware checks each erase and write
operation to ensure the affected addresses are outside
of the boot block. Erase/write operations within the boot
block are silently skipped.
On PIC16 devices, program memory is paged. There- Having write access to Configuration bits is very
fore, the PCLATH register needs to be loaded before powerful, but also dangerous. If a design only has
executing a far GOTO. The host PC bootloader applica- enough hardware for operating from the internal oscil-
tion will write up to four instructions at the Reset vector lator and accidentally changes the Configuration bits to
(address, 0000h) to jump to the bootloader at start-up. use EC mode, all further operation could be prevented,
To make room, the first four application firmware including Bootloader mode.
instructions are automatically moved by the host PC Configuration bits can be write-protected in software
software to reside just before the bootloader firmware. with the USE_SOFTCONFIGWP option in the include file,
bootconfig.inc. PIC16 devices do not have
Configuration bit write access.

 2010 Microchip Technology Inc. DS01310A-page 9

AN1310
HARDWARE WRITE PROTECTION FIGURE 11: MEMORY, WITH
Certain PIC18 devices, such as the PIC18F46J11, WRITE-PROTECTED AREA
provide Configuration bits to allow write protection of
the end of the Flash memory space. Bootloader Reset Vector 0000 h

Most devices, however, only provide write protection High Priority Interrupt Vector 0008 h
from the beginning of the Flash memory space. For Low Priority Interrupt Vector 0018 h
these devices, it will be necessary to locate the boot-
loader at address, 0h, in Flash memory. To do that, use
the #define BOOTLOADER_ADDRESS 0 option in the Bootloader Firmware
bootconfig.inc file.
Application Reset Vector 0400 h
When located at address, 0h, the bootloader occupies
the hardware Reset and interrupt vector addresses. Application Interrupt Vector 0408 h
For this layout to work, application firmware must Application Interrupt Vector 0418 h
provide remapped Reset and interrupt vectors. The
bootloader firmware will “pass-through” hardware
Reset and interrupt events to the application firmware
at the remapped addresses (see Figure 11).
Note: Some PIC devices provide configuration
Application Firmware
options that can write-protect application
firmware’s program memory regions.
Write-protected regions will not be
modifiable by the bootloader.
If the pre-existing contents of write- Write-Protected,
protected regions do not match the new “Boot Block” Area
data in the application firmware’s hex file,
write protection may prevent the boot- The bootconfig.inc file defines where the
loader write operation from completing bootloader firmware looks for the following application
successfully. vectors: AppVector, AppHighIntVector and AppLowInt
Vector. To optimize usage of Flash memory for a specific
application, these addresses can be adjusted. For now,
however, leave the addresses at their default values to
maintain compatibility with the example application
firmware projects.

DS01310A-page 10  2010 Microchip Technology Inc.

 AN1310
APPLICATION MODE MPLAB® IDE C18 Applications
CONSIDERATIONS When using the MPLAB IDE C18 compiler to develop
Having bootloader code in Flash memory may require application firmware, the first Reset vector instruction
some changes to application firmware. To facilitate generated by the C compiler is, by default, a “GOTO”.
that, this application note provides software mecha- This allows the bootloader to be used with no code
nisms and example application firmware projects that changes required.
should work “out of the box” on all configurations. The C18 compiler grows application code from the
Placing the bootloader firmware towards the end of beginning of program memory space, with minimal
Flash memory space should require little or no changes fragmentation. This allows the bootloader firmware, by
to application firmware, due to the automatic Reset default, to stay resident at the end of program memory
vector remapping done by the host PC bootloader space without conflicting with application firmware
software. Interrupt vectors are handled by application code. As a result, it is usually unnecessary to modify
firmware at the normal hardware interrupt vector linker scripts to reserve program memory space for the
addresses, so no application firmware changes are bootloader firmware.
required in this design. For an example memory map of
PIC18 MCC18 REMAPPED APPLICATION
this design type, see Figure 10 on page 9.
EXAMPLE
If the bootloader code is placed at address, 0h, the
application firmware will have to support remapping of Example remapped application firmware for MCC18 on
the hardware Reset and interrupt vectors to new loca- PIC18 is installed to:
tions. These new vector locations will be used by C:\Microchip Solutions\Serial
“pass-through” bootloader firmware occupying the Bootloader AN1310 vX.XX\PIC18 Application\
hardware vector addresses. For an example memory MCC18 Remapped Application\
map of this design type, see Figure 11 on page 10.
This section discusses how the example application The C code for this project contains all of the necessary
firmware projects were modified to operate with modifications to operate with a bootloader at address,
bootloader firmware in both design types. 0h. All of the work is done through C code (see
Example 3).
Note: The example application firmware projects
are intended to communicate via UART1
on the PIC device. Unlike the bootloader
firmware, no auto-baud code is included.
Before compiling, edit the example source
code to provide the correct Baud Rate
Generator (BRG) value, based on the
clock frequency and the baud rate desired.
The source code gives some common
values in commented sections.

 2010 Microchip Technology Inc. DS01310A-page 11

AN1310
EXAMPLE 3: PIC18 REMAPPED APPLICATION C CODE
// Prevent application code from
// being written into FLASH
// memory space needed for the
// Bootloader firmware at
// addresses 0 through 3FFh.
#pragma romdata BootloaderProgramMemorySpace = 0x6
const rom char bootloaderProgramMemorySpace[0x400 - 0x6];

// The routine _startup() is

// defined in the C18 startup
// code (usually c018i.c) and
// is usually the first code to be called by a GOTO at the
// normal reset vector of 0.

extern void _startup(void);

// Since the bootloader isn't

// going to write the normal
// reset vector at 0, we have
// to generate our own remapped
// reset vector at the address
// specified in the
// bootloader firmware.
#pragma code AppVector = 0x400
void AppVector(void)
{
_asm GOTO _startup _endasm
}

// For PIC18 devices the high

// priority interrupt vector is
// normally positioned at
// address 0008h, but the
// bootloader resides there.
// Therefore, the bootloader's
// interrupt vector code is set
// up to branch to our code at
// 0408h.
#pragma code AppHighIntVector = 0x408
void AppHighIntVector(void)
{
_asm GOTO high_isr _endasm // branch to the high_isr()
// function to handle priority
// interrupts.
}
#pragma code AppLowIntVector = 0x418
void low_vector(void)
{
_asm GOTO low_isr _endasm // branch to the low_isr()
// function to handle low
// priority interrupts.
}
#pragma code // return to the default
// code section

There are no assembly language helper files, project build options or customized linker scripts for remapping application
vectors in Example 3. Everything is handled by the code.

DS01310A-page 12  2010 Microchip Technology Inc.

 AN1310
HI-TECH C® Applications FIGURE 13: BUILD OPTIONS DIALOG
BOX
The HI-TECH C compiler often fragments application
code into portions of program memory space that con-
flict with the bootloader firmware. To prevent problems
with application code conflicting with bootloader firm-
ware sharing the same device program Flash memory,
the HI-TECH C project must be modified to reserve
program memory space for the bootloader.
The addresses used by the bootloader firmware can be
determined by looking at the Flash memory display
inside the host PC bootloader application. While con-
nected to the bootloader, scroll down to the end of
Flash memory space where you can find the dark Set the “ROM ranges” field to something like the
turquoise shaded memory region reserved for the following:
bootloader (see Figure 12). default,-F800-FBFF
The word, “default”, tells the compiler to use the entire
FIGURE 12: BOOTLOADER MEMORY,
Flash program memory space of the device, while the
HIGHLIGHTED address range, “-F800-FBFF,” with a minus sign in
Bootloader begins front, tells the compiler to exclude addresses, F800h
at address F800h through FBFFh, from being used for the application
firmware.
This prevents application code from conflicting with the
bootloader code.

Add the bootloader region to be reserved in the HI-

TECH C project’s “Build Options”, under the Global tab
(see Figure 13).

 2010 Microchip Technology Inc. DS01310A-page 13

AN1310
PIC16 HI-TECH C REMAPPED APPLICATION PIC18 HI-TECH C REMAPPED APPLICATION
EXAMPLE EXAMPLE
By default, example remapped application firmware for By default, example remapped application firmware for
HI-TECH C on PIC16 devices is installed to: HI-TECH C on PIC18 is installed to:

C:\Microchip Solutions\Serial C:\Microchip Solutions\Serial

Bootloader AN1310 vX.XX\PIC16 Application\ Bootloader AN1310 vX.XX\PIC18 Application\
HI-TECH C Remapped Application\ HI-TECH C Remapped Application\

At first glance, the C code for this project looks pretty The code for this project is normal application code.
similar to normal application code. However, some There is no need for an assembly language helper file,
slight changes are made: as required for PIC16 devices. Instead, only build
• An assembly language helper file (isr.as) is added options need to be configured.
to handle Reset and interrupt vector remapping.
1. Select Project>Build Options...>Project and go
This file should be copied into user’s projects and to the Linker tab menu.
can be customized with an alternative to the “ORG
The “Codeoffset” field has been set to 400.
0x400” Reset vector address. The 0x400 address
should match the bootloader AppVector setting. This address must be equal to the bootloader
• The Codeoffset option is reset to 404. defined AppVector address in order for the
HI-TECH C compiler to generate Reset and
The Codeoffset hex number must always be equal interrupt vector code further into Flash memory
to the application Reset vector plus four space than the default of address, 0h.
(AppVector + 4). This causes the HI-TECH C com-
piler to generate Reset and interrupt vector code 2. Go to the Global tab menu and review the ROM
further into Flash memory space than the default ranges field.
of address 0. This option has been set to prevent the
To verify this, open the project in MPLAB IDE, HI-TECH C compiler from using Flash memory
select Project>Build Options...>Project and go to space from address, 0h, through the end of the
the Linker tab menu. bootloader firmware.
• To prevent the HI-TECH C compiler from using Note: If the size of the bootloader firmware and
the RAM at address, 7Eh and 7Fh, the RAM write-protected boot block permits, the
ranges option is set to default,-7E-7F end address can be adjusted to free more
The bootloader uses access bank RAM at 7Eh and Flash memory for the application code.
7Fh to pass the PCLATH and WREG registers, For now, leave the end address as:
respectively, to the assembly language helper default,-0-3FF.
code in the file, isr.as. The address numbers
used must match the PCLATH_TEMP and On PIC18 devices, there is no need to exclude RAM
W_TEMP address definitions in the bootloader ranges. The PIC18 bootloader does not use any RAM
firmware source code. to save context data when passing through control to
your application’s interrupt vector code.
To verify this, open the project in MPLAB IDE,
select Project>Build Options...>Project and go to
the Global tab menu.
Note: Enhanced architecture PIC16F devices pro-
vide automatic hardware to save and restore
ISR context during interrupt handling. Thus,
it is possible to omit the “RAM ranges”
setting on enhanced core PIC16 devices.
• The ROM ranges option is set to prevent the
HI-TECH C compiler from using Flash memory
space from address, 0h, through the end of the
bootloader firmware.
Depending on the size of the bootloader firmware
and write-protected boot block, the end address to
be excluded may be changed to free more Flash
memory for application code.
To verify this, go to the same Global tab menu.

DS01310A-page 14  2010 Microchip Technology Inc.

 AN1310
SOFTWARE DESIGN TABLE 4: EXAMPLE WRITE PLAN
This section discusses the host PC software and write Erase List
planning for the bootloader application. Start Address End Address
1F800h 1F400h
Host PC Software
1C00h 0h
The host PC application accepts the following
20000h 1FC00h
command-line options:
Write List
Serial Bootloader.exe [/e] [/p] [/v]
[filename.hex] Start Address End Address
/e – Erase the device. 1FFC0h 20000h
/p – Program the device with the specified hex file.
0h 1AC0h
/v – Verify that the device matches the data in the
specified hex file. 1F7C0h 1F800h

Software used for building the host PC software DEVELOPING THE WRITE PLAN
includes:
In the Write Plan process:
• Qt SDK 4.x – Lesser General Public License soft-
1. Regions of Flash memory space are added to
ware, used unmodified and dynamically linked
the Write List, aligned to the Flash write block
• QextSerialPort 1.2 – Public domain software, heavily boundaries. Any blocks of memory that are
modified for this application found to contain empty data (such as NOPs) are
• SQLite 3.6.x – Public domain software, used excluded from being added to the Write List.
unmodified 2. The Write List is copied to create the Erase List,
Using only open source and public domain develop- except that memory address regions are aligned
ment tools/libraries facilitates porting the software to to Flash erase block boundaries.
other operating system platforms, such as Linux®, or Using Erase and Write Lists makes it easy to re-
Macintosh®. As of this writing, the software is known to order the memory regions to be erased or
compile and work on Linux. No testing has been done written first, for fail-safe operation in case of
for Macintosh. interruption during a write operation.
On “J” family devices, where Configuration bits
Write Planning
are stored at the end of Flash memory, the Flash
The original bootloader application, documented in erase block with Configuration bits is scheduled
AN851, used a simple algorithm for writing new to be erased last. The Flash write block contain-
firmware: erase all memory and write all memory with ing the new Configuration bits is scheduled to be
new data. written immediately afterwards, as the first write
transaction.
With large memory devices, such as the PIC18F87J11,
erasing all of Flash memory can take almost four Scheduling Configuration bits’ erase/write
seconds, followed by the transferring of 128 Kbytes of minimizes the time that Configuration bits could
new Flash data at 115.2 kbps, which can take another be left blank on the device.
11 seconds or more, at lower baud rates. 3. Flash memory is erased in descending order by
When developing new application firmware, typically the erase block address.
the target PIC microcontroller has far more Flash This ensures that being interrupted will force the
memory than what is needed by application firmware. bootloader to stay in Bootloader mode on the
As a result, the earlier bootloader’s simple algorithm next Reset, rather than attempt starting partially
can become noticeably inefficient. erased application firmware.
This serial bootloader incorporates a different algo-
rithm, “write planning”. The application firmware hex file
is analyzed to produce two lists of memory regions:
Erase and Write. These lists form a “Write Plan” that
the software uses to issue erase and write commands
to the bootloader firmware kernel. For an example
Write Plan, see Table 4.

 2010 Microchip Technology Inc. DS01310A-page 15

AN1310
EXECUTING THE WRITE PLAN CODE PROTECTION
After generating the plan, the Erase List is used to Some PIC devices provide “Code-Protect” Configura-
erase all necessary Flash memory and the Write List is tion bit options. Code-protect is intended to prevent
used to rewrite necessary Flash memory. ICSP™ read-out of device memory contents.
To prevent leaving “junk” data in previously programmed When the PIC device is programmed with this boot-
Flash memory regions that the new firmware no longer loader firmware, however, code protection can be
uses, the following additional steps are taken: easily circumvented. This bootloader performs table
1. The entire Flash memory space is verified by reads on device memory contents whether “code-
calculating a 16-bit CCITT CRC against each protect” Configuration bits are enabled or not. This
Flash erase block, both on the device and on the could allow the application to be read by an attacker.
host PC. For applications where security is a concern, AN1157,
The calculated CRC values should match, “A Serial Bootloader for PIC24F Devices” (DS01157),
unless a block on the device contains leftover may be more appropriate. An encryption-enabled
junk data that needs to be erased. version of AN1157 may be ordered from Microchip
sales offices.
2. The host PC compares CRC values calculated
on the device and the desired CRC values
calculated on the host PC. When a block needs SUPPORTING NEW DEVICES
to be erased to match the desired CRC value, it To enable the serial bootloader to keep pace with the
is added to a new Erase List. If erasing the block release of new, enhanced microcontrollers, it employs
will not make it match the desired CRC value, an a SQLite™ database on the host PC. The PC software
error is displayed. quickly reviews device information when connecting to
3. The new Erase List is executed to clear any the bootloader firmware. The database can be updated
leftover junk data from old firmware. without recompiling the host PC software.
Using CRC numbers enables the bootloader to deal The bootloader firmware needs to have the same
with junk data without having to transfer the entire adaptability, but obviously can not use a database.
memory contents back to the host PC or resort to Instead, the bootloader firmware relies on the include
blindly erasing every Flash memory address. This file, DEVICES.INC, to provide device-specific
algorithm significantly speeds up reprogramming of information at compile time.
devices with prior data.
With this approach, updating support for a new device
TABLE READS simply requires adding the new device information to
the database and include files, assuming code
Some PIC devices provide Configuration bit options for compatibility with the new device.
“Table Read Protect,” which can prevent bootloader
table read operations.
Modifying the SQLite™ Database
The bootloader firmware needs to be able to perform
table reads for the following operations: By default, the SQL source code to the device
database is installed to:
• Read Flash program memory contents
• Generate CRC values to find junk data for final C:\Microchip Solutions\Serial
pass erase Bootloader AN1310 vX.XX\Device Database\
devices.sql
• Generate CRC values to verify correct Flash
memory contents
• Read Device and Revision ID numbers to look up
essential device characteristics database
information
Because this bootloader requires extensive use of
table reads, enabling “Table Read Protect”
Configuration bits is not recommended.

DS01310A-page 16  2010 Microchip Technology Inc.

 AN1310
The database currently has two tables: DEVICES and This allows the verify operation to mask off un-
CONFIGWORDS. used Configuration Word bits to avoid a possible
To update the SQLite database for a new device: false verify failure.

1. Add a single DEVICES record, using an SQL 3. Regenerate the binary devices.db database
insert statement like that shown in Example 4. file, used at run time by the host PC software:
• Go to the following command prompt path:
EXAMPLE 4: SQL INSERT STATEMENT
insert into DEVICES values ( C:\Microchip Solutions\Serial
161, -- Device ID (in decimal) Bootloader AN1310 vX.XX\Device Database
4, -- Family ID (2 for PIC16, 4 for
PIC18) • Run the following command:
'PIC18F8722',
2, -- Bytes Per Word (FLASH) sqlite3.exe -init devices.sql -batch
64, -- Write FLASH Block Size ..\devices.db .quit
64, -- Erase FLASH Page Size
'0x0', -- Start address of FLASH The updated devices.db file must be kept in the
'0x20000', -- End address of FLASH same folder as the host PC serial bootloader
'0xF00000', -- Start address of EEPROM executable file.
(use 0 if no EEPROM on your device)
'0xF00400', -- End address of EEPROM
'0x200000', -- Start address of User ID
Modifying the DEVICES.INC Include File
(use 0 if no User ID space on your device) To update the DEVICES.INC file for a new device:
'0x200008', -- End address of User ID
'0x300000', -- Start address of Config 1. In MPLAB IDE, open the bootloader firmware
Bits project file appropriate for the new device.
'0x30000E', -- End address of Config 2. Open the DEVICES.INC file.
Bits
'0x3FFFFE', -- Start address of Device
3. Add a new #ifdef block for the new device, as
Id shown in Example 6.
'0x400000', -- End address of Device Id The device numbers in the DEVICES.INC file
'0xFFE0', -- Device Id Mask (so that must match those used in the SQL database
Revision ID bits are ignored) script (Example 5).
'0x0', -- Start address of GPR
'0xF60' -- End address of GPR (tells the EXAMPLE 6: INCLUDE FILE ADDITION
PC software how big packets can be #ifdef __18F8722
-- without overflowing the #define DEVICEID .161
device buffer RAM) #define WRITE_FLASH_BLOCKSIZE .64
); #define ERASE_FLASH_BLOCKSIZE .64
#define END_FLASH 0x20000
2. If the new device uses configuration fuses, add #define END_GPR 0xF60
records to the CONFIGWORDS table for each #endif
Configuration Word, as shown in Example 5.
EXAMPLE 5: CONFIGWORDS ADDITIONS Simplifying Device Data Collection
insert into CONFIGWORDS values ( The device and family numbers required in the preced-
161, -- Device ID ing examples can be obtained from the devices’ data
4, -- Family ID
sheets, programming specifications and reference
'CONFIG1H', -- Config Name
3145729, -- Address
manuals. The data can be acquired more easily, how-
'0x37', -- Default Value ever, by using Microchip’s XML “essential device
'0xCF' -- Implemented Bits characteristics” files.
); These XML files, used to generate the MPLAB
processor-specific header files, MPLAB configuration
insert into CONFIGWORDS values (
screens and other items, are in a compressed file
161, -- Device ID
4, -- Family ID
stored on the host PC during the MPLAB IDE installa-
'CONFIG2L', -- Config Name tion. A “Device Database” utility program can generate
3145730, -- Address the SQL and include information for new devices.
'0xFF', -- Default Value
'0x1F' -- Implemented Bits
);

(...)

 2010 Microchip Technology Inc. DS01310A-page 17

AN1310
To use the utility: REFERENCES
1. Go to the following path and decompress the
Brant Ivey, AN1157, “A Serial Bootloader for PIC24F
bundled XML files.
Devices” (DS01157), Microchip Technology Inc., 2008.
C:\Program Files\Microchip\ Ross M. Fosler and Rodger Richey, AN851, “A FLASH
MPLAB IDE\Device\*PIC.zip Bootloader for PIC16 and PIC18 Devices” (DS00851),
Microchip Technology Inc., 2002.
2. Go to the following path and run the executable
file, Device Database.exe:
Alternative References
C:\Microchip Solutions\
For information on other bootloaders, visit the following
Serial Bootloader AN1310 vX.XX\
web sites:
The utility’s dialog box appears. • USB bootloaders —
http://www.microchip.com/usb
3. Select File>Open PIC Definitions and select the
PIC file(s) for the desired device(s) (for • TCPIP bootloaders —
example, PIC18F6520.PIC). http://www.microchip.com/tcpip
• dsPIC® DSCs and 32-bit bootloaders —
To generate information for more than one
http://www.microchip.com/pic32libraries
device, hold down <Ctrl> as you select the
second and subsequent PIC file names, before
clicking the Open button.
The utility displays the device information on the
devices.inc tab, as shown in Figure 14.

FIGURE 14: DEVICE DATABASE UTILITY

DS01310A-page 18  2010 Microchip Technology Inc.

 AN1310
APPENDIX A: BOOTLOADER <DLE> is used to escape a byte that could be inter-
preted as a control character. The bootloader will
PROTOCOL
always accept the byte following a <DLE> as data and
The bootloader employs a basic communication protocol will always send a <DLE> before any of the control
that is robust, simple to use and easy to implement. characters. The data payload and CRC bytes will be
escaped by <DLE> characters when the data happens
Packet Format to match a control character.
The <STX> or “Start of TeXt” control character (0x0F in
All data packets transmitted from the host PC to the
hexadecimal) serves multiple purposes: auto-baud,
microcontroller follow the basic packet format:
flow control and packet framing.
[<STX>…]<STX>[<DATA>…]<CRCL><CRCH><ETX>[<ETX>] For establishing initial communications, the pulse width
<...> – Represents a byte of the <STX> character is measured by the bootloader
[...] – Represents an optional or variable number firmware to calculate the rate at which the host PC is
of bytes transmitting data (auto-baud).
The host PC will transmit <STX> characters to the
The maximum packet length is constrained by the microcontroller up until the microcontroller echoes
microcontroller’s RAM. Host PC software should deter- back an <STX> character of its own. The host PC must
mine what device is being used and look up the RAM not begin transmitting the data payload field until an
size in the essential device characteristics database to echoed <STX> character is received back from the
avoid sending more data than can be buffered by the microcontroller. If data were to be transmitted immedi-
microcontroller. For a working implementation, see the ately, without an echoed <STX> character, data could
example host PC software source code and be lost because the microcontroller firmware is busy
Device.cpp and the maxPacketSize() function. performing auto-baud or some other task.
Most response data packets transmitted from the boot- The <ETX> or “End of TeXt” control character (0x04 in
loader firmware, back to the host PC, follow a similar hexadecimal) marks the end of the packet. Sending an
basic packet format: extra <ETX> can also be used by the host PC software
to force a baud rate locked bootloader back into its
[<STX>…]<STX>[<DATA>…]<CRCL><CRCH><ETX>
auto-baud routine. This provides a faster and more reli-
able resynchronization for baud rate changes made on
Maximum response packet length is limited by the
the host PC.
number of blocks requested by the host PC software in
the command packet.
Cyclic Redundancy Check (CRC)
Control Characters A 16-bit CCIT CRC algorithm is used to ensure that
received data has not been corrupted by the serial
There are three control characters that have special
communication link. A 16-bit CRC may detect bursts of
meaning. Two of them, <STX> and <ETX>, are shown
bad data, up to 15 bits in length, while simple checksum
in the previous examples. The remaining character is
algorithms can be unreliable at detecting multi-bit
“Data Link Escape”, <DLE> (0x05 in hexadecimal).
errors.
TABLE 5: CONTROL CHARACTERS The 16-bit CCIT CRC algorithm is the same CRC
Control Hex Description algorithm specified in the MMC/SD Card SPI protocol
commonly used by embedded applications. A free,
<STX> 0Fh Start of TeXt easy-to-use CRC calculator and source code generator
<ETX> 04h End of TeXt are available from Thomas Pircher’s “pycrc” tool:
<DLE> 05h Data Link Escape http://www.tty1.net/pycrc/
The bootloader firmware and host PC software calcu-
late the CRC against each byte of the data payload,
excluding control characters. If the calculated CRC
does not match the transmitted CRC, the packet is
assumed to be corrupted and is discarded.
The CRC algorithm is doubly useful for quickly verifying
that Flash memory has been programmed correctly.
Calculating CRC values against blocks of Flash mem-
ory can be done much faster than transferring every
byte of Flash memory across a slow serial
communications link.

 2010 Microchip Technology Inc. DS01310A-page 19

AN1310
Bootloader Commands

Read Bootloader Information

Request
<STX> <0x00> <CRCL><CRCH> <ETX>

PIC18 Response
<STX> <BOOTBYTESL><BOOTBYTESH> <VERSIONL><VERSIONH> <COMMANDMASKH> <COMMANDMASKL:FAMILYID>
<STARTBOOTL><STARTBOOTH><STARTBOOTU><0x00> <CRCL><CRCH> <ETX>

PIC16 Response
<STX> <BOOTBYTESL><BOOTBYTESH> <VERSIONL><VERSIONH> <COMMANDMASKH> <COMMANDMASKL:FAMILYID>
<STARTBOOTL><STARTBOOTH><STARTBOOTU><0x00> <DEVICEIDL><DEVICEIDH> <CRCL><CRCH> <ETX>

Details
CRC for the request packet is, conveniently, always 0x0000 for this packet.
• VERSION defines the version number of the bootloader firmware.
• BOOTBYTES specifies the boot block size, in bytes.
• STARTBOOT specifies the starting Flash memory address for the boot block.
Together, STARTBOOT and BOOTBYTES are used in the host PC software to color the bootloader Flash memory
region turquoise.
• COMMANDMASK is currently unused on PIC18.
For PIC16, COMMANDMASKH will contain 0x01 if the device implements the erase Flash command. Otherwise, it
contains 0x00, signifying that the PIC16 device does automatic erases during writes (for example, PIC16F88X family).
• FAMILYID is a four-bit number in the least significant nibble, indicating what kind of microcontroller is in use.
Currently used family IDs are: 2 – PIC16, 4 – PIC18.
• DEVICEID is only transmitted for PIC16 devices. It is a compile-time value indicating exactly which PIC16FXXX
part number is being used.
PIC18 parts do not need to transmit the DEVICEID here because the host PC application can use the read Flash
memory command, below, to read the device ID from configuration memory at address 0x3FFFFE.
The host PC application uses the Family ID and Device ID to look up the correct device information in the essential
device characteristics database.

Read Flash Memory

Request
<STX> <0x01> <ADDRESSL><ADDRESSH><ADDRESU><0x00> <BYTESL><BYTESH> <CRCH><CRCL> <ETX>

Response
<STX> [DATA…] <CRCL><CRCH> <ETX>

Details
• ADDRESS is the beginning Flash memory address from which to start reading.
• BYTES specifies the number of bytes to read.

DS01310A-page 20  2010 Microchip Technology Inc.

 AN1310
Read CRCs of Flash Memory
Request
<STX> <0x02> <ADDRESSL><ADDRESSH><ADDRESSU><0x00> <BLOCKSL><BLOCKSH> <CRCL><CRCH> <ETX>

Response
<STX>[<CRC1L><CRC1H>…<CRCnL><CRCnH>]<ETX>

Details
• ADDRESS is the beginning Flash memory address from which to start reading.
• BLOCKS specifies that number of 16-bit CRC words to generate. Each 16-bit CRC is generated on erase Flash
block size number of bytes.
Note that the response packet of this command does not provide a CRC of the data payload, which is a little different
from most of the packets. This allows the bootloader firmware to avoid having to calculate two different CRCs at
the same time, reducing memory use and processing time.

Erase Flash Memory

Request
<STX> <0x03> <ADDRESSL><ADDRESSH><ADDRESSU><0x00> <PAGESL> <CRCL><CRCH> <ETX>

Response
<STX> <0x03> <CRCL><CRCH> <ETX>

Details
• ADDRESS is the last Flash memory address to start erasing from. Erases are performed in descending address
order, which is backwards from normal operations.
This feature can help the bootloader to fail more safely in some situations.
• PAGES specifies the number of erase Flash block size pages of Flash memory.

Write Flash Memory

Request
<STX> <0x04> <ADDRESSL><ADDRESSH><ADDRESSU><0x00> <BLOCKSL> [<DATA>…] <CRCL><CRCH> <ETX>

Response
<STX> <0x04> <CRCL><CRCH> <ETX>

Details
• ADDRESS is the Flash memory address to start writing to. Writes are performed in ascending address order.
• BLOCKS specifies the number of write Flash block size chunks of Flash memory to write.
Flash memory cells must be erased before writing can be performed on the same cells again.

 2010 Microchip Technology Inc. DS01310A-page 21

AN1310
Read EEPROM
Request
<STX> <0x05> <ADDRESSL><ADDRESSH><0x00><0x00> <BYTESL><BYTESH> <CRCH><CRCL> <ETX>

Response
<STX> [DATA…] <CRCL><CRCH> <ETX>

Details
• ADDRESS is the beginning EEPROM address from which to start reading.
• BYTES specifies the number of bytes to read.
Microcontrollers that do not have EEPROM immediately send the response packet with a dummy payload of 0x05.

Write EEPROM
Request
<STX> <0x06> <ADDRESSL><ADDRESSH><0x00><0x00> <BYTESL><BYTESH> [<DATA>…] <CRCL><CRCH> <ETX>

Response
<STX> <0x06> <CRCL><CRCH> <ETX>

Details
• ADDRESS is the EEPROM address to start writing to. Writes are performed in ascending address order.
• BYTES specifies the number of bytes to write to EEPROM.
EEPROM does not require erasing before rewriting, thus, there is no erase command.
Microcontrollers that do not have EEPROM immediately send the response packet without performing any action.

Write Config Fuses

Request
<STX> <0x07> <ADDRESSL><ADDRESSH><0x00><0x00><BYTES> [<DATA>…] <CRCL><CRCH> <ETX>

Response
<STX> <0x07> <CRCL><CRCH> <ETX>

Details
• ADDRESS is the Configuration address to start writing to. Writes are performed in ascending address order.
• BYTES specifies the number of bytes to write.
Config bits do not require erasing before rewriting, so there is no erase command.

Run Application Firmware

Request
<STX> <0x08> <CRCL><CRCH> <ETX>

Response
None.

Details
This command makes the bootloader jump to the application firmware Reset vector. No response is returned because
the bootloader is no longer active once application firmware is started.

DS01310A-page 22  2010 Microchip Technology Inc.

Note the following details of the code protection feature on Microchip devices:
• Microchip products meet the specification contained in their particular Microchip Data Sheet.

• Microchip believes that its family of products is one of the most secure families of its kind on the market today, when used in the
intended manner and under normal conditions.

• There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our
knowledge, require using the Microchip products in a manner outside the operating specifications contained in Microchip’s Data
Sheets. Most likely, the person doing so is engaged in theft of intellectual property.

• Microchip is willing to work with the customer who is concerned about the integrity of their code.

• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not
mean that we are guaranteeing the product as “unbreakable.”

Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of our
products. Attempts to break Microchip’s code protection feature may be a violation of the Digital Millennium Copyright Act. If such acts
allow unauthorized access to your software or other copyrighted work, you may have a right to sue for relief under that Act.

Information contained in this publication regarding device Trademarks

applications and the like is provided only for your convenience
The Microchip name and logo, the Microchip logo, dsPIC,
and may be superseded by updates. It is your responsibility to
KEELOQ, KEELOQ logo, MPLAB, PIC, PICmicro, PICSTART,
ensure that your application meets with your specifications.
rfPIC and UNI/O are registered trademarks of Microchip
MICROCHIP MAKES NO REPRESENTATIONS OR
Technology Incorporated in the U.S.A. and other countries.
WARRANTIES OF ANY KIND WHETHER EXPRESS OR
IMPLIED, WRITTEN OR ORAL, STATUTORY OR FilterLab, Hampshire, HI-TECH C, Linear Active Thermistor,
OTHERWISE, RELATED TO THE INFORMATION, MXDEV, MXLAB, SEEVAL and The Embedded Control
INCLUDING BUT NOT LIMITED TO ITS CONDITION, Solutions Company are registered trademarks of Microchip
QUALITY, PERFORMANCE, MERCHANTABILITY OR Technology Incorporated in the U.S.A.
FITNESS FOR PURPOSE. Microchip disclaims all liability Analog-for-the-Digital Age, Application Maestro, CodeGuard,
arising from this information and its use. Use of Microchip dsPICDEM, dsPICDEM.net, dsPICworks, dsSPEAK, ECAN,
devices in life support and/or safety applications is entirely at ECONOMONITOR, FanSense, HI-TIDE, In-Circuit Serial
the buyer’s risk, and the buyer agrees to defend, indemnify and Programming, ICSP, Mindi, MiWi, MPASM, MPLAB Certified
hold harmless Microchip from any and all damages, claims, logo, MPLIB, MPLINK, mTouch, Octopus, Omniscient Code
suits, or expenses resulting from such use. No licenses are Generation, PICC, PICC-18, PICDEM, PICDEM.net, PICkit,
conveyed, implicitly or otherwise, under any Microchip PICtail, PIC32 logo, REAL ICE, rfLAB, Select Mode, Total
intellectual property rights. Endurance, TSHARC, UniWinDriver, WiperLock and ZENA
are trademarks of Microchip Technology Incorporated in the
U.S.A. and other countries.
SQTP is a service mark of Microchip Technology Incorporated
in the U.S.A.
All other trademarks mentioned herein are property of their
respective companies.
© 2010, Microchip Technology Incorporated, Printed in the
U.S.A., All Rights Reserved.
Printed on recycled paper.

Microchip received ISO/TS-16949:2002 certification for its worldwide

headquarters, design and wafer fabrication facilities in Chandler and
Tempe, Arizona; Gresham, Oregon and design centers in California
and India. The Company’s quality system processes and procedures
are for its PIC® MCUs and dsPIC® DSCs, KEELOQ® code hopping
devices, Serial EEPROMs, microperipherals, nonvolatile memory and
analog products. In addition, Microchip’s quality system for the design
and manufacture of development systems is ISO 9001:2000 certified.

 2010 Microchip Technology Inc. DS01310A-page 23

 WORLDWIDE SALES AND SERVICE
AMERICAS ASIA/PACIFIC ASIA/PACIFIC EUROPE
Corporate Office Asia Pacific Office India - Bangalore Austria - Wels
2355 West Chandler Blvd. Suites 3707-14, 37th Floor Tel: 91-80-3090-4444 Tel: 43-7242-2244-39
Chandler, AZ 85224-6199 Tower 6, The Gateway Fax: 91-80-3090-4123 Fax: 43-7242-2244-393
Tel: 480-792-7200 Harbour City, Kowloon Denmark - Copenhagen
India - New Delhi
Fax: 480-792-7277 Hong Kong Tel: 45-4450-2828
Tel: 91-11-4160-8631
Technical Support: Tel: 852-2401-1200 Fax: 45-4485-2829
Fax: 91-11-4160-8632
http://support.microchip.com Fax: 852-2401-3431
India - Pune France - Paris
Web Address:
Australia - Sydney Tel: 91-20-2566-1512 Tel: 33-1-69-53-63-20
www.microchip.com
Tel: 61-2-9868-6733 Fax: 91-20-2566-1513 Fax: 33-1-69-30-90-79
Atlanta Fax: 61-2-9868-6755
Japan - Yokohama Germany - Munich
Duluth, GA
China - Beijing Tel: 49-89-627-144-0
Tel: 678-957-9614 Tel: 81-45-471- 6166
Tel: 86-10-8528-2100 Fax: 49-89-627-144-44
Fax: 678-957-1455 Fax: 81-45-471-6122
Fax: 86-10-8528-2104 Italy - Milan
Boston Korea - Daegu
China - Chengdu Tel: 39-0331-742611
Westborough, MA Tel: 82-53-744-4301
Tel: 86-28-8665-5511 Fax: 39-0331-466781
Tel: 774-760-0087 Fax: 82-53-744-4302
Fax: 86-28-8665-7889 Netherlands - Drunen
Fax: 774-760-0088 Korea - Seoul
China - Chongqing Tel: 82-2-554-7200 Tel: 31-416-690399
Chicago
Tel: 86-23-8980-9588 Fax: 82-2-558-5932 or Fax: 31-416-690340
Itasca, IL
Tel: 630-285-0071 Fax: 86-23-8980-9500 82-2-558-5934 Spain - Madrid
Fax: 630-285-0075 China - Hong Kong SAR Tel: 34-91-708-08-90
Malaysia - Kuala Lumpur
Tel: 852-2401-1200 Tel: 60-3-6201-9857 Fax: 34-91-708-08-91
Cleveland
Independence, OH Fax: 852-2401-3431 Fax: 60-3-6201-9859 UK - Wokingham
Tel: 216-447-0464 China - Nanjing Tel: 44-118-921-5869
Malaysia - Penang
Fax: 216-447-0643 Tel: 86-25-8473-2460 Fax: 44-118-921-5820
Tel: 60-4-227-8870
Dallas Fax: 86-25-8473-2470 Fax: 60-4-227-4068
Addison, TX China - Qingdao Philippines - Manila
Tel: 972-818-7423 Tel: 86-532-8502-7355 Tel: 63-2-634-9065
Fax: 972-818-2924 Fax: 86-532-8502-7205 Fax: 63-2-634-9069
Detroit China - Shanghai Singapore
Farmington Hills, MI Tel: 86-21-5407-5533 Tel: 65-6334-8870
Tel: 248-538-2250 Fax: 86-21-5407-5066 Fax: 65-6334-8850
Fax: 248-538-2260
China - Shenyang Taiwan - Hsin Chu
Kokomo Tel: 86-24-2334-2829 Tel: 886-3-6578-300
Kokomo, IN Fax: 86-24-2334-2393 Fax: 886-3-6578-370
Tel: 765-864-8360
Fax: 765-864-8387 China - Shenzhen Taiwan - Kaohsiung
Tel: 86-755-8203-2660 Tel: 886-7-536-4818
Los Angeles Fax: 86-755-8203-1760 Fax: 886-7-536-4803
Mission Viejo, CA
Tel: 949-462-9523 China - Wuhan Taiwan - Taipei
Fax: 949-462-9608 Tel: 86-27-5980-5300 Tel: 886-2-2500-6610
Fax: 86-27-5980-5118 Fax: 886-2-2508-0102
Santa Clara
Santa Clara, CA China - Xian Thailand - Bangkok
Tel: 408-961-6444 Tel: 86-29-8833-7252 Tel: 66-2-694-1351
Fax: 408-961-6445 Fax: 86-29-8833-7256 Fax: 66-2-694-1350

Toronto China - Xiamen

Mississauga, Ontario, Tel: 86-592-2388138
Canada Fax: 86-592-2388130
Tel: 905-673-0699 China - Zhuhai
Fax: 905-673-6509 Tel: 86-756-3210040
Fax: 86-756-3210049

01/05/10

DS01310A-page 24  2010 Microchip Technology Inc.