SPRUIU8A March   2020  – August 2021 TMS320F280040-Q1 , TMS320F280040C-Q1 , TMS320F280041 , TMS320F280041-Q1 , TMS320F280041C , TMS320F280041C-Q1 , TMS320F280045 , TMS320F280048-Q1 , TMS320F280048C-Q1 , TMS320F280049 , TMS320F280049-Q1 , TMS320F280049C , TMS320F280049C-Q1

 

  1.   Trademarks
  2. 1Introduction
  3. 2Resources Required for LFU
  4. 3Memory Layout
  5. 4Static Code in LFU
  6. 5LED Example Application and LFU Flow
  7. 6Running the LED Example
    1. 6.1 Serial Flash Programmer Update
    2. 6.2 Programming Static Code – Loading via Code Composer Studio (CCS)
    3. 6.3 Live Firmware Update of Application
    4. 6.4 Limitations and Troubleshooting
  8. 7Revision History

4 Static Code in LFU

Static code that is used to support LFU consists of:

  • Bank Selection Logic – when there are two (or more) Flash banks containing application firmware, logic that determines which Flash bank to boot is necessary. A common implementation of this logic centers on a firmware revision number. As described, the lower revision number is the latest image in this Example. Bank selection logic is placed at the default flash boot address (0x80000 in F28004x), so that once Boot ROM code completes execution, execution will transfer to bank selection logic. Bank selection logic is only included in Bank0, not in Bank1.
  • Flash Kernel – it is the job of the Flash kernel to receive the Firmware image from the host using a peripheral, and call the Flash programming APIs to write it to flash memory. In this document, the SCI flash Kernel is used since the SCI peripheral is used to transfer the new firmware image. The detailed step by step flow is documented in the file header of flashapi_ex2_ldfu.c.
    • In a blank device (where application firmware is not present in either flash banks) the bank selection logic will identify there is no valid KEY in either Flash bank, and will wait for an LFU command over SCI. This will use the Flash Kernel to update the firmware on to bank1 as the kernel code is first programmed to bank0, and therefore executes from bank0.
    • If one or both banks contains a valid application, bank selection logic will transfer control to the code entry point (codestart) of the corresponding bank. In this example, the codestart address is 0x8EFF0 for Bank0 and 0x9EFF0 for Bank1.
    • During LFU, the application will make a call to the Flash Kernel to receive and update the firmware.
  • Flash API – Flash APIs provide interfaces to erase and program Flash memory. These APIs need to run from the bank which is NOT being updated.

The static code is configured as a single example - flashapi_ex2_sci_kernel project (included in C2000Ware at <C2000Ware>\driverlib\f28004x\examples\flash). This example supports multiple build configurations, of which those relevant to LFU are listed below:

  • BANK0_LDFU - Links the bank selection logic and flash kernel to Bank 0 (addresses 0x80000 - 0x81FFF). Uses Flash API symbols in flash.
  • BANK0_LDFU_ROM - Links the bank selection logic and flash kernel to Bank 0 (addresses 0x80000 - 0x81FFF). Uses Flash API symbols in ROM; Rev A of F28004x cannot be used with this build configuration, since it does not support Flash APIs in ROM.
  • BANK1_LDFU - Links the flash kernel to Bank 1 (0x90000 - 0x91FFF). Uses Flash API symbols in flash.
  • BANK1_LDFU_ROM - Links the flash kernel to Bank 1 (0x90000 - 0x91FFF). Uses Flash API symbols in ROM; Rev A of F28004x cannot be used with this build configuration, since it does not support Flash APIs in ROM.

For more details, see the flashapi_ex2_sciKernel.c in the flashapi_ex2_sci_kernel project (included in C2000Ware at <C2000Ware>\driverlib\f28004x\examples\flash).