TIDUEY4D August   2022  – December 2022

 

  1.   Description
  2.   Resources
  3.   Features
  4.   Applications
  5.   5
  6. 1System Description
    1. 1.1 Key System Specifications
  7. 2System Overview
    1. 2.1 Block Diagram
    2. 2.2 Design Considerations
      1. 2.2.1 Building Blocks
      2. 2.2.2 Flash Partitioning
      3. 2.2.3 LFU Switchover Concepts
      4. 2.2.4 Application LFU Flow
  8. 3Hardware, Software, Testing Requirements, and Test Results
    1. 3.1 Hardware Requirements
    2. 3.2 Software Requirements
      1. 3.2.1 Software Package Contents
      2. 3.2.2 Software Structure
    3. 3.3 Introduction to the TIDM-DC-DC-BUCK
    4. 3.4 Test Setup
      1. 3.4.1 Loading the Custom Bootloader and Application to Flash using CCS
    5. 3.5 Test Results
      1. 3.5.1 Running the LFU Demo with Control Loop Running on the CPU
      2. 3.5.2 Running the LFU Demo with Control Loop Running on the CLA
      3. 3.5.3 LFU Flow on the CPU
      4. 3.5.4 LFU Flow on the CLA
      5. 3.5.5 Assumptions
      6. 3.5.6 Preparing Firmware for LFU
      7. 3.5.7 LFU Compiler Support
      8. 3.5.8 Robustness
      9. 3.5.9 LFU Use-Cases
  9. 4FOTA Example
    1. 4.1 Abstract
    2. 4.2 Introduction
    3. 4.3 Hardware Requirements
    4. 4.4 Software Requirements
    5. 4.5 Running the example
  10. 5Design and Documentation Support
    1. 5.1 Software Files
    2. 5.2 Documentation Support
    3. 5.3 Support Resources
    4. 5.4 Trademarks
  11. 6Terminology
  12. 7About the Author
  13. 8Revision History

2.2.3 LFU Switchover Concepts

The key considerations when preparing firmware for LFU are operational continuity and LFU switchover time. Operational continuity is achieved through persistence of state, which means keeping common static and global variables in RAM at the same addresses between firmware versions, and avoiding re-initialization of those variables when the new firmware takes effect. Compiler support for LFU is used to enable persistence of state.

Activating the new firmware involves branching from old firmware to the LFU entry point of the new firmware, execute the compiler's LFU initialization routine, arrive inside main() of the new image, and perform any additional initialization. This is where interrupts are briefly disabled, initialization that needs interrupts to be disabled is performed (e.g. Interrupt vector updates, function pointer updates), before interrupts are re-enabled. This last time interval is defined as the LFU switchover time.

LFU is simplified when there is hardware support to swap Flash banks [2], where either Flash bank can be mapped to a fixed address space, considered the Active bank. The Inactive bank is mapped to a different address space, and is the bank that is updated. C2000™ MCUs do not currently support Flash bank swap, so the user will need to keep track of the Flash bank where application firmware will be resident, and make the necessary assignments and adjustments in a linker command file.

Function pointers and Interrupt vectors need to be re-initialized inside main(), since their locations will be different between Flash banks. C2000™ MCUs support a large number of interrupt vectors (typically 192), so it is not practical to re-initialize all of them. Usually, only a few are used, and the rest are assigned to a default vector. The F28003x device contains LFU specific hardware features (Interrupt vector swapping, RAM block swapping) that enable reduction in the LFU switchover time.

If there are changes to array sizes or addition of variables to a structure, the user needs to manage these appropriately, by using pragmas early in the development cycle to place arrays and structures at fixed locations, but with sufficient headroom to account for their potential growth in future firmware. With this approach, only newly added fields need to be initialized.