In the above LFU demo, two application images were used. One that runs on Flash Bank0, and another that runs on Flash Bank1. The BANK0_FLASH build configuration is considered the “old” or “reference” firmware, and the BANK1_FLASH build configuration is considered the “new” firmware. These two applications are otherwise identical. There are no source code differences between them; however the new firmware has 25 new floating point variables that are defined and initialized. These two applications are implemented through two build configurations of the TIDM-DC-DC-BUCK solution project – BANK0_FLASH, and BANK1_FLASH. As the name suggests, BANK0_FLASH executes from Flash Bank0, and BANK1_FLASH from Flash Bank1. These two build configurations share the same source files, but contain different linker command files. Also, at various places in the code, Macros “#ifdef BANK0” and “ifdef BANK1” control execution. They run the same Control loop ISR and Background tasks.

The following represents the high-level LFU flow when the Control loop runs on the CPU.

1. On device reset, execution starts at the default boot to flash entry point, 0x80000, which is where the bank selection logic function is located. This function checks if there is a valid application present in either or both Flash banks, and if one is present, it picks the more recent version and branches to it (either 0x8EFF0 or 0x9EFF0). These are the code_start locations for the respective applications, from where execution enters the C runtime initialization routine (_c_int00), and into main() of the corresponding application. If neither Flash bank contains a valid application, execution waits to auto-baud lock with the host, and for the host to send an image over SCI.
2. User invokes LFU command “8 Live DFU” through Windows command prompt.
3. The target device receives a command ID “0x700” in the SCI Receive Interrupt ISR.
4. In main(), in the background loop, a function BUCK_LFU_runLFU() is called. When the command ID matches “0x700”, the SCI interrupt is disabled and execution branches to the address of the Live DFU (liveDFU()) function in the custom bootloader. If the Application in Bank0 is executing, then the branch is made to the custom bootloader in Bank0 (address 0x81000). If the Application in Bank1 is executing, then the branch is made to the custom bootloader in Bank1 (address 0x91000).

5. liveDFU() in the custom bootloader receives an application image from the host and programs it into Flash. After completing, execution depends on whether the macro LFU_WITH_RESET is defined. If it is, the Watchdog is configured to generate a Reset signal, and then enabled, so a device reset occurs. If the macro is not defined, execution branches to the LFU entry point of the new application image. This is 0x8EFF8 for Bank 0 and 0x9EFF8 for Bank 1. This is different from the regular Flash boot entry point.

6. The function c_int_lfu() is located at 0x8eff8 on Bank 0 and 0x9eff8 on Bank 1. This function enables LFU switchover without a device reset. In this function:
   1. The compiler's LFU initialization routine (__TI_auto_init_warm()) is invoked. This initializes any variables that have been indicated as needing initialization. So it initializes the 25 new floating point variables defined in the BANK1_Flash build configuration.
   2. A flag is set to indicate LFU is in progress. On F28004x, this is done using a software variable lfuSwitch. On F28003x, this is done by setting the LFU.CPU bit of the LFUConfig SysCtl register using LFU_setLFUCPU().
   3. main() is called

7. In main(), initialization progresses depending on whether or not LFU is in progress. This is done by accessing the LFU.CPU bit of the LFUConfig SysCtl register on F28003x, or lfuSwitch on F28004x. If the value is 0, initialization progresses as if a device reset occurred.

8. If the value is not 0, then limited initialization is performed. First, init_lfu() is executed. This function copies over code from Flash to RAM, corresponding to Program code that the user has indicated needs to run from RAM. Next, on F28003x, it updates the inactive PIE interrupt vector table using Shadow_Interrupt_Register(). On F28004x, the interrupt vector table swapping hardware feature is not available, so this is not performed. On F28003x, a set of inactive function pointers is also updated. On F28004x, the RAM block swapping hardware feature is not available, so this is not performed.
9. Next, a variable lfuSwitch_start is set to Lfu_switch_wait_for_isr. Execution waits here until the next Control loop ISR executes, where lfuSwitch_start moves from Lfu_switch_wait_for_isr to Lfu_switch_ready_to_switch. This helps synchronize the LFU switchover to the end of the Control loop ISR, which allows maximizing the utilization of the idle time between Control loop interrupts.
10. When execution proceeds, the LFU switchover steps occur. First, global interrupts are disabled. On F28003x, PIE interrupt vector table swapping and RAM block swapping are executed. On F28004x, every used PIE interrupt vector needs to be individually updated here. Likewise, every function pointer needs to be individually updated here. Then C28x CPU side stack pointer initialization is performed, and global interrupts are re-enabled. This represents the end of the LFU switchover.
11. Global interrupts are disabled for a short duration. If a peripheral interrupt occurs during this time, it would continue to stay latched and interrupt the CPU when global interrupts are re-enabled. This is done to avoid unpredictable behavior in the unlikely event an interrupt occurs and this vector table is accessed while it is being updated.
12. Figure 3-9 shows another LFU use-case where control loop parameters are updated between firmware versions. In practice, this can be done in real-time using the Compensation Designer, but this use-case is included for illustrative purposes. This corresponds to the buck_F28004x_lfu_controlloop project. In this project, the BANK0_FLASH build configuration contains coefficients that correspond to a smaller gain, Kdc = 4000. The BANK1_FLASH build configuration contains coefficients that correspond to a larger gain Kdc = 38904 (refer to the function BUCK_initControlLoopGlobals() in buck.h). This leads to poorer transient performance with the BANK0_FLASH build configuration and more optimal transient performance with the BANK1_FLASH build configuration, when Active Load is enabled. If the device already contains the Application files corresponding to the buck_f28004x_lfu project (or even the CLA side), this update can be run using the same LFU commands as in the previous section, except with the updated .txt names corresponding to this project as shown in Table 3-1. In the buck_f28004x_lfu_controlloop project, Active load is enabled in main() on a device reset (not after an LFU switch), so it is important to reset the device after running the LFU, so that this initialization is performed. The device reset needs to be done only once.

    Then the user can perform additional LFU updates with the controlloop project executables, without device reset.

Figure 3-9 LFU Switchover with Transient Performance Improvement – Control Loop on CPU