AN247 A CAN Bootloader for PIC18F CAN Microcontrollers The drawback to this is a lack of efficiency, as directly Author: Ross M. Fosler manipulating the target memory and manually verifying Microchip Technology Inc. data takes significant time on the CAN bus. To make the operation more efficient, the programming INTRODUCTION target could be given some intelligence, like self- verification. This would make communications Among the many features built into Microchips unidirectional, essentially cutting the time on the CAN Enhanced FLASH Microcontroller devices is the capa- bus in half. bility of the program memory to self-program. This very useful feature has been deliberately included to give Overall, the best savings is to design all the nodes in the user the ability to perform bootloading operations. the system with similar, modular firmware. Each node Devices like the PIC18F458 are designed with a desig- could then use only those modules required for its task, nated boot block, a small section of protectable pro- but the entire group of nodes could be updated simul- gram memory allocated specifically for bootload taneously. The sacrifice here is program memory over- firmware. head, since some nodes may have resident firmware that is not used. This application note demonstrates a simple boot- loader implementation for the PIC18F families of micro- Programming a Running System controllers with a CAN module. The goals of this implementation are to stress maximum performance An interesting situation is bootloading in an active and and functionality, while requiring a minimum of code functioning system. In this instance, one or more of the space. For users developing CAN enabled systems, it nodes are taken off-line to update their firmware, yet provides a low level framework that can be used with the functionality of the entire system is not completely higher level network protocols to develop more disabled. This, of course, requires that the target node complex and custom-tailored systems. or nodes have some functional independence from other parts of the networked system. CONSIDERATIONS FOR FIELD There are priority issues to contend with when pro- PROGRAMMING OVER THE CAN BUS gramming in an active system. For example, what pri- ority can be given to the bootloader without affecting The combination of FLASH technology and robust net- the critical communications in the system If higher pri- work communication capability in a single device ority is given to nodes running the bootloader than makes over-the-network programmability a very desir- other nodes running their normal application, then it able option. However, this makes bootloading on a may take time for data to be received when data is CAN bus network a very different challenge from more being streamed to the programming target. Thus, criti- typical uses, such as using a bootloader to program a cal systems that require relatively low latency for data single FLASH device in isolation. Lets consider some transmission or reception may fail to function as of the key issues in over-the-network programming. expected. In the opposite situation, assigning the pro- gramming target with a priority that is too low could lead Single or Group Programming to extremely long programming times, simply because the programming source and target are continually Providing bootloading capability over a CAN bus net- waiting for an IDLE bus to pass data. work takes some forethought. For example, a system with a number of nodes may have identical firmware in In an active network, planning is necessary to provide several nodes. Since every node on a CAN bus can sufficient bus time for programming. One solution is see all passing data, it may be more efficient to simply to give relatively high priority to bootloader pro- program these identical nodes in a single pass. gramming operations, then design the programming source to inject time for other applications while However, in other cases where a node or many nodes streaming data on the CAN bus. Thus, bus time is are unique, it may only be necessary to open always available and controlled by the programming peer-to-peer communications to program the device. source. This can be the simplest programming system, because the programming source could contain all the intelligence and freely manipulate the target memory. 2003 Microchip Technology Inc. DS00247A-page 1AN247 Even with careful planning, there may be situations FIGURE 1: BOOTLOADER FUNCTIONAL where safety is actually compromised as a result of bus BLOCK DIAGRAM contention. In these cases, the best option may be to RX TX put all nodes in the network into a Configuration mode and shut down all system functions. Bootloader Firmware CAN Boot Mode Entry Data Control/Data Buffer Module Boot mode entry is determined by an event. This could be a hardware event, such as pressing one or more (Msg Identifier) buttons after a device RESET. It could also be a net- CONTROL/DATA work event, such as a special set of data that tells a device to enter Boot mode. One example is a network D8 PUT/GET boot ID that is mapped directly into the CAN ID. Then Bootloader the key, along with specific target information, could be Control FLASH Registers embedded in the data field of a CAN frame. The key Program D0 information could put one or more nodes into Boot Memory mode. EE Data Memory BOOTLOADER FIRMWARE Memory I/O Logic Configuration Memory Basic Operation Overview An overview of the CAN bootloaders operation is shown in Figure 1. A CAN Message Identifier and data is received through the CAN module. One bit in the FIGURE 2: PROGRAM MEMORY MAP OF identifier is used to indicate whether to PUT or GET THE PIC18F458 data. Another is used to determine if the message is to be interpreted as data to be programmed or bootloader 0000h control information. Writing data automatically invokes Boot Program the appropriate function to write to memory (FLASH, RESET Vector 0200h Data EEPROM, or Configuration Memory). Writing to the Control registers sets the operation of the High Priority Interrupt Vector 0208h bootloader. Low Priority Interrupt Vector 0218h The bootloader can be configured at build time to sup- port one of two mutually exclusive modes of operation. In P Mode (or Put-only) mode, the microcontroller only accepts PUT commands, and never talks back to the source. In PG Mode, both PUT and GET commands are accepted, allowing the source to both read from and write to the targets memory. A more detailed explanation is provided in subsequent sections. Memory Organization Program Memory 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. This bootloader is designed to occupy the current designated boot block of 512 bytes 7FFFh (or 256 words) of memory using the recommended options. Note, however, some compile time options can Note: Memory areas not shown to scale. grow the bootloader beyond the boot block. Figure 2 shows a memory map of the PIC18F458. The boot area can be code protected to prevent accidental overwriting of the boot program. DS00247A-page 2 2003 Microchip Technology Inc. User Memory Space