A Serial Bootloader for PIC24F Devices - Microchip …

1 2008 Microchip Technology 1AN1157 INTRODUCTIONOne of the advantages of Microchip s PIC micro-controllers with self-programmable enhanced Flashmemory is the ability to implement a Bootloader . Thisallows designers to implement applications that can beupdated many times over, potentially extending theapplication s useful application note describes a Serial Bootloader for16-bit PIC24F Devices using the UART module as acommunication channel. The Bootloader applicationuses the communication protocols originally outlined inMicrochip Application Note AN851, A Flash Bootloaderfor PIC16 and PIC18 Devices . Some modifications tothe original protocol have been made to maintaincompatibility with the PIC24 architecture. It has alsobeen redesigned to accommodate the current genera-tion of PIC24FJ Flash microcontrollers, as well as thenext generation of PIC24F OperationFigure 1 summarizes the essential firmware design ofthe Bootloader .

2 Data is received through the UART module and passed through the transmit/receiveengine. The engine filters and parses the data, storingthe information into a data buffer in RAM. The com-mand interpreter evaluates the command informationwithin the buffer to determine what should be done( , Is the data written into memory? Is data read frommemory? Does the firmware version need to be read?).Once the operation is performed, reply data is passedback to the transmit/receive engine to be transmittedback to the source, closing the software flow 1: Bootloader FUNCTIONAL BLOCK DIAGRAMCOMMUNICATIONSThe microcontroller s UART module is used to receiveand transmit data; it is configured to be compatible withRS-232 communications. The device can be set up inan application to bootload from a computer through itsstandard Serial interface. The following defaultcommunication settings are used: 8 Data Bits No Parity 1 Stop Bit Automatic Baud Rate DetectionThe baud rate is detected using the UART module shardware auto-baud functionality.

3 For more informationon this feature, refer to the UART chapter of the PIC24F Family Reference Manual (Section 21. UART (DS39708)).Author:Brant IveyMicrochip Technology *UxTXUxRXRegisters*BootloaderControlFirm wareData Bus* If present on target device. See text for Serial Bootloader for PIC24F DevicesAN1157DS01157A-page 2 2008 Microchip Technology RECEIVE/TRANSMIT BUFFERAll data is moved through a buffer (referred to as thereceive/transmit buffer). The buffer is a maximum of261 bytes deep. This is the maximum packet lengthsupported by the protocol. Figure 2 shows an exampleof the mapping of the buffer withinPIC24 FJXXXGAXXX useful feature of the receive/transmit buffer is that itmaintains the data from the last received packet. Thisallows commands to be easily repeated by sending anempty packet (a packet with no command code ordata).

4 If an empty packet is received, the data in thebuffer will be reused as if it were just 2:DATA MEMORY USAGE ON PIC24 FJXXXGAXXX Devices COMMAND INTERPRETERThe command interpreter decodes and executesvarious protocol commands. A complete list of the com-mands is provided in Appendix A: PIC24F SerialBootloader Command Summary . The commandsallow for read, write and erase operations on all types ofnonvolatile memory: program Flash, data EEPROM andConfiguration bits. Additionally, there are commands forspecial operations, such as repeating the last command,replicating the data and resetting the device. Memory OrganizationPROGRAM MEMORY USAGEThe Bootloader requires between 2 Kbytes Kbytes of program memory, depending on the con-figured feature set and compiler optimization. In defaultconfiguration, the Bootloader is designed so that it canbe placed anywhere in memory; by default it is locatedstarting at address 000400h (shown in Figure 3).

5 The Bootloader should not be placed in the same512-byte page of memory as the interrupt vectors orConfiguration Words. This is to allow the Bootloader tomodify these locations without erasing itself. If possible,the Bootloader should be placed in a hardware protected boot block area on Devices which support this boot block can be protected from device self writesand erases so that the Bootloader will not be at risk ofcorrupting itself. Software block protection is provided inthe Bootloader to provide this functionality for devicesthat do not have built-in boot block 3:PROGRAM MEMORY MAP FOR THE Bootloader IN PIC24FJ128GA0XX DEVICESNote:The command set is designed to supportfuture Devices and not all devicesimplement all types of memory. Com-pile-time options are provided to disableunsupported commands to save codespace. Be sure to check which types ofmemory are implemented on the devicebeing used and set the Buffer2800h0000hSFR Area0918hby BootloaderReset VectorsUser Code Reset00004hProgram MemoryUser Memory Space15800hNote:Memory areas not shown to Time-out Value00400hBootloader CodeAvailable forApplication Code00C00h00C02h00C04hFlash Configuration Wordsfor Application Code157 FCh 2008 Microchip Technology 3AN1157 RESET VECTORSTo ensure that the Bootloader is always accessible, it isnecessary to run the Bootloader first after a deviceReset.

6 Therefore, the device s hardware Reset vector(addresses 000000h and 000002h) is used to store thebootloader s Reset vector. If the Bootloader s Resetvector is ever overwritten, the device would no longerbe able to enter Boot mode. For the Bootloader to call the user application, it muststore the user application s Reset vector in constant, USER_PROG_RESET, defined , tells the Bootloader where the Reset vectoris remapped. When a user application is being pro-grammed, the Bootloader will automatically relocatethe user Reset vector from 000000h to the locationdefined in this constant. The Bootloader will read thislocation on device start-up and branch to the addressstored here. When using boot block protection, it is necessary tolocate the user application Reset vector outside of thehardware boot block, so that it can be erased and writ-ten by the Bootloader .

7 Optionally, the application linkerscript can be modified to remove the Reset vector. Ifthis is done, the user application will need to manuallyplace its own Reset vector in the remapped VECTORSB ecause the Interrupt Vector Tables (IVTs) are locatedin the same page of memory as the device s Reset vec-tor, it is good practice to remap the vector tables to anew location, so that the Reset vector does not need tobe erased to update interrupt locations. Remapping theIVTs is required when hardware boot block protection isenabled. This is done by modifying Bootloader andapplication linker scripts. The Bootloader linker scriptentry for the interrupt tables indicates what addresseswill be placed in the IVT. The entries for the interrupts being used should bemodified to indicate the locations in the user applicationof the interrupt functions, so that the service routine canbe called directly (Option A in Figure 4).

8 If the locationsof the interrupts are not known at the time the boot-loader is compiled, change the addresses in the linkerscript to locations where branch instructions can beplaced as part of user code. The user applicationshould then place branch instructions in these locationsto vector to the interrupt routines (Option B in Figure 4).Note that this method increases the interrupt latency bytwo instruction cycles to allow for the extra branchinstruction to application linker script must be modified toremove the interrupt vectors, to prevent the bootloaderfrom erasing the remapped interrupt vectors. Alterna-tively, you can enable the Bootloader mode whichprevents the vector table from being erased, so that theuser application linker script does not need to linker scripts where these modifications havebeen done have been provided in the folder, gld.

9 Mod-ified linker examples are shown in Appendix C: Example Linker Scripts for Use with the PIC24 FBootloader .FIGURE 4:TECHNIQUES FOR REMAPPING INTERRUPT VECTORS Note:Memory areas not shown to Vectors00004hIVTs00000h00200hApplication CodeISR for Interrupt X01004hInterrupt X Vector:1004h FixedInterrupt XReset Vectors00004hIVTs00000h00200hApplication CodeGOTO 0x110001004hInterrupt X Vector:1004h FixedInterrupt XISR for Interrupt X01100hOption A: Direct Mapping to ISRO ption B: Mapping an ISR through a Branch Instruction(Fixed Location)(Fixed Instruction Location)(Variable ISR Location)AN1157DS01157A-page 4 2008 Microchip Technology ProtocolThe Bootloader employs a basic communication proto-col that is robust, simple to use and easy to protocol was originally specified in AN851. It hasbeen slightly modified to improve compatibility with the16-bit PIC24F architecture by increasing the maximumpacket FORMATAll data that is transmitted to or from the device followsthe basic packet format:<STX> <STX>[<DATA> <DATA>.]

10 ]<CHKSUM> <ETX>where each <..> represents a byte and [..] representsthe data field. The start of a packet is indicated by two Start of TeXt control characters (<STX>), and is termi-nated by a single End of TeXt control character(<ETX>). The last byte before the <ETX> is always achecksum, which is the two s complement of the LeastSignificant Byte of the sum of all data bytes. The datafield is limited to 261 data bytes. This length is used inorder to allow a full row of data to be received at a more bytes are received, then the packet is ignoreduntil the next <STX> pair is CONTROL CHARACTERST hree control characters have special meaning. Two ofthem, <STX> and <ETX>, are introduced above. Thelast character not shown is the Data Link Escape ,<DLE>. Table 1 provides a summary of the threecontrol 1:CONTROL CHARACTERSThe <DLE> is used to identify a value that could beinterpreted in the data field as a control the data field, the Bootloader will always acceptthe byte following a <DLE> as data, and will alwayssend a <DLE> before any of the three control charac-ters.