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.5 Assumptions

  1. LFU implementation on F28003x is limited to 2 Flash banks in the design. However, the device can contain up to 3 Flash banks, and the LFU implementation can be extended to cover 3 banks.
  2. Bank selection logic is present only on Flash Bank0.
  3. Once LFU command processing begins, the background tasks of TIDM-DC-DC-BUCK stop running. If users want to implement LFU and want the background loop or portions of it to continue running during LFU command processing, they may want to consider moving those portions into an ISR (for example, a CPUTimerISR).
  4. The Control loop ISR is specified with a “#pragma INTERRUPT(ISR_name, HPI).” The HPI refers to High Priority Interrupt, which uses a fast context save and cannot be nested. The SCI Receive interrupt ISR is not specified as HPI. So it defaults to LPI or Low Priority Interrupt, which can be nested. Furthermore, the Control loop ISR is triggered by an ADCB1 interrupt, which belongs to Interrupt group 1 on F28004x/F28003x, higher in priority than the SCIA_RX interrupt, which belongs to Interrupt group 9.
  5. The default ISR assigned to PIE vectors that are not explicitly assigned remains unchanged.
  6. SFRA is disabled during LFU – this is because SFRA and the LFU Host share the same SCI peripheral. With the current Hardware configuration, it is not possible to support both, since the Launchpad only supports one SCI channel from the host to the device.
  7. Since Flash bank swapping is not supported, a specific Firmware version has to be mapped to a specific Flash Bank.
  8. The object output type for the application firmware is EABI.
  9. .bss (uninitialized data) is made NOINIT since EABI by default zero-initializes uninitialized variables. Initialization of global variables is done by a user function in main(). This is not required and can be done by the C run-time initialization routine as well.
    Note:

    NOINIT does not impact __TI_auto_init_warm().

  10. This comment is specific to F28004x - C2000Ware contains Flash API libraries built for COFF and for EABI. The EABI-based library is a Flash API library that runs from ROM. This is included in the application project. For consistency, ROM build configurations are used with the custom bootloader (flashapi_ex2_sci_kernel) project as well.
  11. If the user's application contains multiple ISRs, including Nested ISRs, LFU switchover will need to occur in idle time when none of the ISRs are running. The user may choose, based on their specific application use-case, the optimal idle time period if there are idle-time periods of varying durations. The entire LFU process, including the final LFU switchover, occurs in the background, for example, during idle-time.
  12. C28x and CLA LFU switchover occur asynchronously, based on the assumption that code running on the C28x and code running on the CLA are independent enough to allow this asynchronous switchover. If they are dependent, and a synchronous switchover is required, then the process of LFU switchover needs to be modified. First, the CLA LFU switchover time needs to be identified. This corresponds to the "CLA background task stopped" interrupt from the CLA to the C28x CPU. Now the CLA is ready for switchover, but should not switchover. The C28x LFU switchover time now needs to be identified. Once this is identified, both the C28x and CLA are ready for switchover, and can switchover simultaneously.