Stellaris Boot Loader User's Guide - Texas …

1 Copyright 2007-2013 Texas Instruments IncorporatedSW-BOOTLDR-UG-10636 user S GUIDES tellaris boot LoaderCopyrightCopyright 2007-2013 Texas Instruments Incorporated. All rights reserved. Stellaris and StellarisWare are registered trademarks of Texas and Thumb are registered trademarks and Cortex is a trademark of ARM Limited. Other names and brands may be claimed as the property be aware that an important notice concerning availability, standard warranty, and use in critical applications of Texas Instruments semicon-ductor products and disclaimers thereto appears at the end of this Instruments108 Wild Basin, Suite 350 Austin, TX 78746 Main: +1-512-279-8800 Fax: +1-512-279-8879 InformationThis is version 10636 of this document, last updated on March 28, 28, 2013 Table of ContentsTable of ContentsCopyright..2 Revision Information..21 Introduction..52 Startup Code..93 Serial Update.

2 Packet Handling.. Transport Layer.. Serial Commands..134 Ethernet Update..175 CAN Update.. CAN Bus Clocking.. CAN Commands..196 USB Device (DFU) Update.. USB Device Firmware Upgrade Overview.. Stellaris -Specific USB Download Commands..287 Customization..358 Configuration..379 Source Details.. Autobaud Functions.. CAN Functions.. Decryption Functions.. Ethernet Functions.. File System Functions.. I2C Functions.. Main Functions.. Packet Handling Functions.. SSI Functions.. UART Functions.. Update Check Functions.. USB Device Functions..62 IMPORTANT NOTICE..70 March 28, 20133 Table of Contents4 March 28, 2013 Introduction1 IntroductionThe Texas Instruments Stellaris boot Loader is a small piece of code that can be programmedat the beginning of flash to act as an application Loader as well as an update mechanism for appli-cations running on a Stellaris ARM Cortex -M3-based microcontroller.

3 The boot Loader can bebuilt to use either the UART0, SSI0, I2C0, CAN, Ethernet, or USB ports to update the code on themicrocontroller. The boot Loader is customizable via source code modifications, or simply decidingat compile time which routines to include. Since full source code is provided, the boot Loader canbe completely update protocols are utilized. On UART0, SSI0, I2C0, and CAN, a custom protocol is usedto communicate with the download utility to transfer the firmware image and program it into using Ethernet or USB DFU, however, different protocols are employed. On Ethernet thestandard bootstrap protocol (BOOTP) is used and for USB DFU, updates are performed via thestandard Device Firmware Upgrade (DFU) configured to use UART0, Ethernet, or USB, the LM Flash Programmer GUI can be usedto download an application via the boot Loader . The LM Flash Programmer utility is available fordownload Code OverviewThe following is an overview of the organization of the source code provided with the boot code for performing the auto-baud operation on theUART port.

4 This is separate from the remainder of the UART code so that the linker can remove it when it is not functions for performing a firmware update via the used by the CAN update code to check if a firmware update is required, or if afirmware update is being requested by the for the update check list of commands and return messages supported bythe boot dummy source file used to translate file into a header file that can be included in assem-bly code. This is needed for the Keil tool chain since it is notable to pass assembly source code through the C template for the boot Loader configuration file. This con-tains all of the possible configuration 28, code to perform an in-place decryption of the down-loaded firmware image. No decryption is actually performedin this file; this is simply a stub that can be expanded to per-form the require for the in-place decryption functions for performing a firmware update via the Eth-ernet functions to provide simple FAT file system for the file system functions for transferring data via the I2C0 for the I2C0 transfer linker script used when thecodered,gcc.

5 Orsourcerygxxcompiler is being used to build the linker script used when thervmdkcompiler is beingused to build the boot linker script used when theewarmcompiler is beingused to build the boot linker script used when theccscompiler is being usedto build the boot main control loop of the boot functions for handling the packet processing of com-mands and for the packet handling functions for transferring data via the SSI0 for the SSI0 transfer start-up code used when theccscompiler is being usedto build the boot start-up code used when thecoderedcompiler is beingused to build the boot start-up code used when theewarmcompiler is beingused to build the boot 28, start-up code used when thegcccompiler is being usedto build the boot start-up code used when thervmdkcompiler is beingused to build the boot start-up code used when thesourcerygxxcompiler isbeing used to build the boot functions for transferring data via the UART0 for the UART0 transfer functions implementing the USB DFU protocol cut-down version of the USB library containing supportfor enumeration and the endpoint 0 transactions required toimplement the USB DFU for the functions provided in definitions, labels related to the USB Device FirmwareUpgrade class boot 28, 20137 Introduction8 March 28, 2013 Startup Code2 Startup CodeThe start-up code contains the minimal set of code required to configure a vector table, initializememory, copy the boot Loader from flash to SRAM, and execute from SRAM.

6 Because some toolchain-specific constructs are used to indicate where the code, data, and bss segments reside inmemory, each supported tool chain has its own separate file that implements the start-up start-up code is contained in the following (Code Red Technologies tools) (IAR Embedded Workbench) (GNU GCC) (Keil RV-MDK) (CodeSourcery Sourcery G++) ( Texas Instruments Code Composer Studio)Accompanying the start-up code for each tool chain are linker scripts that are used to place the vec-tor table, code segment, data segment initializers, and data segments in the appropriate locationsin memory. The scripts are located in the following (Code Red Technologies tools, GNU GCC, and CodeSourcery Sourcery G++) (Keil RV-MDK) (IAR Embedded Workbench) (TI Code Composer Studio)The boot Loader s code and its corresponding linker script use a memory layout that exists entirelyin SRAM. This means that the load address of the code and read-only data are not the same asthe execution address.

7 This memory map allows the boot Loader to update itself since it is actuallyrunning from SRAM only. The first part of SRAM is used as the copy space for the boot Loader whilethe rest is reserved for stack and read/write data for the boot Loader . Once the boot Loader calls theapplication, all SRAM becomes usable by the vector table of the Cortex-M3 microprocessor contains four required entries: the initial stackpointer, the reset handler address, the NMI handler address, and the hard fault handler reset, the processor loads the initial stack pointer and then starts executing the reset initial stack pointer is required since an NMI or hard fault can occur at any time; the stackis required to take those interrupts since the processor automatically pushes eight items onto contains the boot Loader s vector table which varies in size based on the ad-dition of the auto-baud feature or USB DFU support.

8 These options requires additional interrupthandlers expand the vector table to populate the relevant entries. Since the boot Loader executesfrom SRAM and not from flash, tool chain-specific constructs are used to provide a hint to the linkerthat this array is located contains the default fault handler. This is a simple infinite loop,effectively halting the application if any unexpected fault occurs. The application state is, therefore,preserved for examination by a debugger. If desired, a customized boot Loader can provide its ownhandlers by adding the appropriate handlers to a reset, the start-up code copies the boot Loader from flash to SRAM, branches to the copy ofthe boot Loader in SRAM, and checks to see if an application update should be performed by callingMarch 28, 20139 Startup CodeCheckForceUpdate(). If an update is not required, the application is called. Otherwise thefunctions that are called are based on the mode of operation for the boot Loader .

9 For UART0, SSI0,and I2C0, the microcontroller is initialized by callingConfigureDevice()and then the boot loadcalls the serial control loopUpdater(). For Ethernet, the microcontroller is initialized by callingConfigureEnet()and then the boot Loader calls the Ethernet control loopUpdateBOOTP().For CAN, the microcontroller is initialized by callingConfigureCAN()and then the boot loadercalls the CAN control loopUpdaterCAN(). For USB, the microcontroller is initialized by callingConfigureUSB()after which the functionUpdaterUSB()configures the USB interface for check for an application update (inCheckForceUpdate()) consists of checking the beginningof the application area and optionally checking the state of a GPIO pin. The application is assumedto be valid if the first location is a valid stack pointer (that is, it resides in SRAM, and has a value ), and the second location is a valid reset handler address (that is, it resides in flash,and has a value of , where the value is odd).

10 If either of these tests fail, then theapplication is assumed to be invalid and an update is forced. The GPIO pin check can be enabledwithENABLE_UPDATE_CHECKin the header file, in which case an update can beforced by changing the state of a GPIO pin (for example, with a push button). If the application isvalid and the GPIO pin is not requesting an update, the application is called. Otherwise, an updateis started by entering the main loop of the boot , the application can call the boot Loader in order to perform an application-directedupdate. In this case, the boot Loader assumes that the application has already configured theperipheral that it will use for the update. This allows the boot Loader to use the peripheral asis to perform the update. The boot Loader also assumes that the interrupt to the core has beenleft enabled as well, which means that that application should not call IntMasterDisable() beforecalling the boot Loader .