SDAA064 November   2025 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3. 1Introduction
  4. 2Building Blocks for LFU
  5. 3Details of Proposed Design
    1. 3.1 Flash Bank Organization
    2. 3.2 LFU Concepts and Factors Impacting Performance
    3. 3.3 Hardware Support for LFU
      1. 3.3.1 A/B Swappable Flash Banks
      2. 3.3.2 Interrupt Vector Table Swap
  6. 4Application LFU Flow
  7. 5Results and Conclusion
  8. 6Example Implementations
  9. 7Summary
  10. 8References

4 Application LFU Flow

In the following, when referring to code and the example projects, SBL = flash_based_uart_sbl_with_lfu and LFU Application = lfu_uart_cpu1_application.

The detailed steps associated with LFU are outlined below:

  1. Boot to the SBL and execute the application: On a device reset, execution starts in the SBL. The communication peripheral is initialized and execution branches to the application's codestart routine. In code, this occurs in the SBL's main() function (flash_based_uart_sbl.c).
  2. Initiate LFU: The user invokes LFU on the target MCU through a host initiated LFU command.
  3. Receive LFU command in the application: The application receives the LFU command in its communication peripheral ISR. In code, this occurs in the LFU Application's SBL_uartNotifyISR() (uart_led_blinky_cpu1.c), which sets a flag to tell the application to jump back into the SBL to process the command.
  4. Process the LFU command: The application branches back into the SBL to parse and process the LFU command. In code, this occurs in the SBL's commandJumpTable() function (flash_based_uart_sbl.c), which reads the command and executes the appropriate operations.
  5. Download the new firmware and program to flash: The LFU flow in the SBL receives the application image from the host and programs it into the inactive flash bank. Background task functions in the old firmware have stopped executing, but control ISRs continue to be available to keep the application functionality unaffected. In code, this happens in the SBL's cpu1LFUFlow() function (sbl_command_flow.c).
  6. Return to application and report success: If the firmware image was programmed successfully, the SBL branches back to the application and reports a successful LFU command
  7. Copy the LFU switchover function into RAM: The application copies the new firmware's LFU switchover function from inactive flash, which is not executable, into RAM, then branches to it. As the old firmware performs the copy of the new firmware's switchover function, it must be located at a fixed address. In code, the LFU Application's performLFUSwitchover() function (lfu_switchover.c) is responsible for this.
  8. Initialize the new PIPE vector table: The shadow PIPE vector table is populated with the new firmware's ISRs. In code, this is done in the LFU Application's lfuSwapBanks() function (lfu_switchover.c).
  9. Wait for the optimal LFU switchover point: A simple state machine with software flags is used to determine the end of a control ISR and the beginning of idle time. This is the optimal time to perform the switchover as it maximizes the use of idle time between control loop interrupts. In code, the lfuSwapBanks function (lfu_switchover.c) accomplishes this by reading the lfu_switchover_proceed flag, which is set at the end of the INT_myCPUTIMER0_ISR() routine (uart_led_blinky_cpu1.c).
  10. Execute the LFU switchover:
    1. Interrupts are disabled
    2. The interrupt tables are swapped
    3. The active and inactive flash banks are swapped
    4. The stack pointer is reinitialized
    5. Interrupts are re-enabled
    6. Execution branches to the new firmware's main() routine

      In code, this is the section of the LFU Application's lfuSwapBanks() function (lfu_switchover.c) marked as the time-critical phase.

  11. Device initialization is skipped in the new firmware, and the background control loop starts executing immediately