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

1. Flash partitioning and high level LFU software flow both remain the same.
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 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 and performs operations described in the previous section.
   1. In this case, with control running on the CLA, a memcpy() is needed to copy code from Flash to RAM.This corresponds to linker command file sections Cla1Prog and.const_cla, and the control loop ISR. In preparation for this memcpy, the corresponding LSRAM sections are reconfigured to where the CPU is the Master of these sections. After the memcpy, these LSRAM sections are once again configured to be shared between the CPU and the CLA.
   2. The CLA background task is disabled.
9. To determine the correct time to execute LFU switchover when the control loop runs on the CLA and a CLA background task is present, the logic is slightly different. First, BUCK_LFU_getBackgroundTaskControlRegister() is used to read the BGSTART bit of the MCTLBGRND register. If the read back value is 0, it means the CLA BGRND task is neither running nor pending. The application is deemed ready for LFU switchover. If the read back value is 1, then the CPU sets the variable lfuSwitch_start to Lfu_switch_waiting_to_switch_cla. An end-of-task interrupt from the CLA BGRND task to the CPU causes the execution of an ISR BUCK_LFU_CLA_BGRND_ISR where lfuSwitch_start changes from Lfu_switch_waiting_to_switch_cla to Lfu_switch_ready_to_switch_cla.
   Note: LFU switchover waits until the CLA background task has stopped because, unlike the other CLA tasks, the CLA background task can be preempted and does not have to run to completion. If a switchover stops the background task while it is executing, it can leave the task is a "non-clean" state. The goal is for the switchover to occur only after all the tasks in the old firmware have completed execution.
10. Further, inside the BUCK_LFU_CLA_BGRND_ISR, after the variable change above, BUCK_LFU_setupCLALFU() is called within which the following steps occur:
    1. CLA task vectors and Background task vector are mapped to the appropriate tasks.
    2. The ISR corresponding to the end-of-task interrupt from the CLA BGRND task to the CPU is registered.
    3. The CLA background task is enabled.
11. When the CLA task vectors are updated, peripheral interrupts would continue to occur. However, CLA tasks always run to completion. Due to this property, no context violation occurs.
12. Another important point to note here is that the .scratchpad section (corresponding to CLA tasks and functions) needs to be assigned to a separate memory section, different from .bss and .bss_cla sections. During LFU, the CLA ISR could be running while the C28x CPU is initializing the new variables. The ISR could be accessing variables located in .bss and .bss_cla sections, and using the .scratchpad as well. In parallel, the variable initialization would be updating .bss_cla sections. To avoid any .scratchpad corruption, their separation is important.
13. Also note that in this case, it is possible for the CLA ISR time during LFU switchover to be increased slightly. This is due to LSRAM memory access conflicts between the CLA and C28x CPU. The CLA ISR runs using .scratchpad and .bss (both located within the RAMLS7 block) while the C28x CPU initializes new variables of the CLA in .bss_cla (also located within the RAMLS7 block).
14. Figure 3-10 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, built with the compiler pre-defined symbol BUCK_CONTROL_RUNNING_ON_CLA. 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. For example, with control loop running on the CPU, assume that BANK1_FLASH was updated last. This means the firmware on BANK1 is executing. So the user will need to execute the LFU command to update BANK0_FLASH (with the CLA side controlloop project executable), not BANK1_FLASH. After the LFU update is complete, a device reset is required. 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-10 LFU Switchover with Transient Performance Improvement – Control Loop on CLA