AN247 Datasheet, PDF (1/32 Pages) Microchip Technology – A CAN Bootloader for PIC18F CAN Microcontrollers

AN247
A CAN Bootloader for PIC18F CAN Microcontrollers
Author: Ross M. Fosler
Microchip Technology Inc.
INTRODUCTION
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 PIC18F458 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 simple boot-
loader implementation for the PIC18F families of micro-
controllers with a CAN module. The goals of this
implementation are to stress maximum performance
and functionality, while requiring a minimum of code
space. For users developing CAN enabled systems, it
provides a low level framework that can be used with
higher level network protocols to develop more
complex and custom-tailored systems.
CONSIDERATIONS FOR FIELD
PROGRAMMING OVER THE CAN BUS
The combination of FLASH technology and robust net-
work communication capability in a single device
makes over-the-network programmability a very desir-
able option. However, this makes bootloading on a
CAN bus network a very different challenge from more
typical uses, such as using a bootloader to program a
single FLASH device in isolation. Let’s consider some
of the key issues in over-the-network programming.
Single or Group Programming
Providing bootloading capability over a CAN bus net-
work takes some forethought. For example, a system
with a number of nodes may have identical firmware in
several nodes. Since every node on a CAN bus can
see all passing data, it may be more efficient to
program these identical nodes in a single pass.
However, in other cases where a node or many nodes
are unique, it may only be necessary to open
peer-to-peer communications to program the device.
This can be the simplest programming system,
because the programming source could contain all the
intelligence and freely manipulate the target memory.
The drawback to this is a lack of efficiency, as directly
manipulating the target memory and manually verifying
data takes significant time on the CAN bus.
To make the operation more efficient, the programming
target could be given some intelligence, like self-
verification. This would make communications
unidirectional, essentially cutting the time on the CAN
bus in half.
Overall, the best savings is to design all the nodes in
the system with similar, modular firmware. Each node
could then use only those modules required for its task,
but the entire group of nodes could be updated simul-
taneously. The sacrifice here is program memory over-
head, since some nodes may have resident firmware
that is not used.
Programming a Running System
An interesting situation is bootloading in an active and
functioning system. In this instance, one or more of the
nodes are taken off-line to update their firmware, yet
the functionality of the entire system is not completely
disabled. This, of course, requires that the target node
or nodes have some functional independence from
other parts of the networked system.
There are priority issues to contend with when pro-
gramming in an active system. For example, what pri-
ority can be given to the bootloader without affecting
the critical communications in the system? If higher pri-
ority is given to nodes running the bootloader than
other nodes running their normal application, then it
may take time for data to be received when data is
being streamed to the programming target. Thus, criti-
cal systems that require relatively low latency for data
transmission or reception may fail to function as
expected. In the opposite situation, assigning the pro-
gramming target with a priority that is too low could lead
to extremely long programming times, simply because
the programming source and target are continually
waiting for an IDLE bus to pass data.
In an active network, planning is necessary to provide
sufficient bus time for programming. One solution is
simply to give relatively high priority to bootloader pro-
gramming operations, then design the programming
source to “inject” time for other applications while
streaming data on the CAN bus. Thus, bus time is
always available and controlled by the programming
source.
 2003 Microchip Technology Inc.
DS00247A-page 1