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

3.5.6 Preparing Firmware for LFU

To perform LFU while making substantial changes between the old and new application images, the user needs to be aware of the following:

  1. LFU Compiler support helps maintain state of common global variables (preserving their address in RAM, and avoiding their initialization during LFU switchover).

    __TI_auto_init_warm() executes in tandem with the old application's ISRs, therefore it does not matter how long __TI_auto_init_warm() takes. This means there is no limitation on the number of variables that need to be initialized.

  2. LFU Switchover timing – this is important when the control loop ISRs run on the C28x CPU. On the F28003x, LFU hardware features on the device like PIE vector swapping and RAM block swapping allow significant flexibility in the number of interrupt vectors and function pointers that need to be updated on LFU. Irrespective of the number of vectors or function pointers, a single cycle swap implements is all that is needed. However, on the F28004x, these hardware features are not present, so each PIE vector and function pointer needs to be individually updated, which proportionately increases LFU switchover time. If this exceeds idle time, then interrupt execution is affected, which is not acceptable.
  3. LFU Switchover timing - in general, this is not an issue when the control loop ISRs run on the CLA. Disabling global interrupts affects only the C28x CPU, not the CLA. CLA tasks (other than the background task) are not disabled and re-enabled during LFU.
  4. Another important aspect to consider is RAM memory overlaps between the custom bootloader (SCI Flash Kernel) and the Application:
    1. In general, avoid RAM section overlaps between SCI Flash Kernel and the Application. If this is not possible, verify using the generated .map files for the SCI Flash Kernel and the Application that there are no RAM memory overlaps, as this will break functionality.
    2. In the case of LFU with the CLA, some LSRAM sections are designated in the Application as Program and some as Data. Ensure that this does not conflict with the SCI Flash Kernel. In other words, do not place Application Program in sections that the SCI Flash kernel is using for data, and vice versa.