TIDUEY4E August   2022  – November 2025

 

  1.   1
  2.   Description
  3.   Resources
  4.   Features
  5.   Applications
  6.   6
  7. 1System Description
    1. 1.1 Key System Specifications
  8. 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
  9. 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 Limitations and Key Concerns
      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
  10. 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
  11. 5Design and Documentation Support
    1. 5.1 Software Files
    2. 5.2 Documentation Support
    3. 5.3 Support Resources
    4. 5.4 Trademarks
  12. 6Terminology
  13. 7About the Author
  14. 8Revision History

3.5.5 Limitations and Key Concerns

  1. Absence of A/B swapping: Since A/B swapping is not supported, the user needs to build firmware for a specific Flash bank. For example, FW_version0 would be targeted to Bank0, FW_version1 to Bank1, FW_version2 to Bank0, FW_version3 to Bank1, and so on.

  2. Use of 3rd Flash bank: 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. One potential use of a third Flash bank is to store the custom bootloader, with the application firmware residing in the first and second Flash banks. This removes the need for the custom bootloader to be placed in the first and second Flash banks.

  3. Ping-pong approach to code in RAM: Any old firmware running from RAM could be running during the LFU process and therefore has to be maintained and untouched by the new firmware. The init_lfu() function which copies code from Flash to RAM of code in the new firmware that needs to run from RAM, should not corrupt the RAM space the old firmware was using. In this sense, a ping-pong like scheme would need to be designed by the user, with a portion of the RAM memory allocated for the LFU image.

  4. Interupt configuration: Interrupt mapping of existing interrupts to the shadow PIE vector table is done in init_lfu() using Shadow_Interrupt_register(). The same process can be followed for any new interrupts that need to be set up. However, they should be enabled (using Interrupt_enable()) only during the LFU switchover. Similarly, any interrupts in the old firmware that are removed will need to be disabled (using Interrupt_disable()) only during the LFU switchover.

  5. Stack initialization: this is done in the LFU switchover in this example so that the SP is reset just prior to executing ISRs of the new firmware. However, main() of the new firmware has already begun executing. If there are local variables in main(), then resetting SP during the LFU switchover can cause a problem. Those local variable values can potentially be lost. An alternate option is to reset SP in the LFU entry point function c_int_lfu(). This entry point is branched to directly, and while inside this function, no ISRs are running, therefore it is safest to reset SP here.

  6. Variables (symbol) management: Update variables are placed in the .TI.update section, whereas preserved variables are placed in the .TI.bound section. But an update variable in one firmware version would become a preserved variable in a later firmware version. It would therefore move from the .TI.update section to the .TI.bound section, while remaining at the same address. This is possible since .TI.bound sections are not required to be contiguous.

  7. Management of static libraries: this example illustrates LFU management of global or static variables in the user's application. It is important to note that if the application links any static libraries which contain global or static variables, LFU management needs to consider those static libraries as well. Library source files need to specify attributes on global or static variables, and the library needs to be compiled by specifying a reference firmware image (just like the firmware it is linked in does). If this is not done, globals within the linked libraries may move location between firmware versions, where the user may incorrectly assume they are preserved.

  8. #pragma DATA_SECTION: this pragma is used to put data in specific sections other than .bss. Another common use case is for peripheral memory mapped registers that have specific locations, and are marked NOINIT so as to avoid erroneous zero initialization on startup. The compiler does not perform LFU initialization of sections defined as DATA_SECTIONS.

  9. Fapi_setActiveFlashBank(): application code does not need to execute Fapi_setActiveFlashBank(). This is managed in the Flash bootloader. Additionally, it is important to disable Flash prefetch before executing this function. Flash prefetch can be enabled after. Otherwise, it can cause an ITRAP. Details are present in the F28003x device errata.

  10. Robustness: in the current example, Flash programming failures or communication issues are not handled as they should be. The user's LFU code should handle these. If a Flash Program/Verify occur occurs, no specific action is taken. In ldfuCopyData(), the section where the START field is programmed checks for a Flash FSM error and calls fmstatfail(). However, in the loop that programs the entire image, this check is not present. Instead a variable 'fail' is incremented.

  11. Bank selection logic: this is present only on Flash Bank0.
  12. Background tasks: 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).

  13. DCSM Security: On F28003x, after LFU, reading DCSM space locks the device for that zone (no need of reset after DCSM configuration to lock the device).

  14. Object output type: the compiler supports LFU only when the object output type for the application firmware is EABI.

  15. 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.
  16. The default ISR assigned to PIE vectors that are not explicitly assigned remains unchanged.
  17. 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.
  18. Since Flash bank swapping is not supported, a specific Firmware version has to be mapped to a specific Flash Bank.
  19. 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.
  20. LFU switchover timing: 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.
  21. C28x and CLA LFU switchover: they 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.