The detailed steps associated with LFU are outlined below:

1. Boot to Bank Selection Logic and Execute Application: 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 for valid applications in the Flash banks, picks the recent most version, and branches to the corresponding firmware version’s entry point (codestart). The entry point is the gateway to the C runtime initialization routine and main() of the application.

2. Initiate LFU: The user invokes LFU on the target MCU through a host initiated LFU command from the host side.

3. Receive LFU command in Application: (Step 1 in Figure 4-4) The application receives the LFU command in its SCI Receive Interrupt ISR (CommandLogISR).

4. Parse LFU command and Branch to LFU Bootloader: (Step 2 in Figure 4-4 ) A specific background task function (Run LFU) parses the LFU command, disables the SCI interrupt, and branches to a LFU function in the LFU bootloader in the same Flash bank, located at a fixed address.

5. Download new Firmware and Program to Flash: (Step 3 in Figure 4-4 ) The LFU function in the LFU bootloader receives an application image from the host and programs it into the Inactive Flash bank. At this point, background task functions in the old firmware have stopped executing, however Control ISRs from the old firmware continue executing to keep the application functionality unaffected.

6. Branch to LFU entry point of new Firmware: (Step 4 in Figure 4-4 ) When the new Firmware is successfully downloaded and programmed, the custom bootloader branches to the LFU entry point (C_int_LFU) of the new application image, located at a fixed address for each Flash bank, and is different from the regular Flash boot entry point (codestart).

6. Execute Compiler LFU Initialization routine and branch to main() of new Firmware: The function at the LFU entry point does the following:

a. The compiler's LFU initialization routine (__TI_auto_init_warm) is invoked. This initializes any variables that have been indicated as needing initialization. (Step 5 in Figure 4-4 ).

b. A flag is set in a hardware LFU register to indicate LFU is in progress.

c. main() is called. (Step 6 in Figure 4-4 ).

7. Perform LFU specific initializations in main() prior to switchover: (Step 7 in Figure 4-4 ) In main(), initialization progresses depending on whether or not LFU is in progress, by checking the above-mentioned flag.

If the flag is set, an LFU initialization function (Init_LFU) copies over any user indicated code from Flash to RAM memory. Next, it updates the inactive interrupt vector table with the interrupt vector locations corresponding to the new firmware. Similarly, a set of inactive function pointers is also updated corresponding to function pointer locations in the new firmware.

8. Wait for optimal LFU switchover point: (Step 8 in Figure 4-4 ) 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 switchover (IdentifyIdleTime), since it allows maximizing the utilization of idle time between Control loop interrupts.

9. Execute the LFU switchover: (Step 9 in Figure 4-4 ) It is important to note that even though execution is already inside main() of the new firmware, old Control loop ISRs are still executing to keep the application functionality unaffected. Once the optimal LFU switchover point is identified, the LFU switchover steps (ActivateApp) occur. First, global interrupts are disabled. Hardware Interrupt vector table swapping and RAM block swapping are executed. Then the stack pointer is re-initialized, and global interrupts are re-enabled. Now, ISRs and background task functions of the new firmware begin executing, representing completion of the LFU switchover. Since global interrupts are disabled for a short duration, an interrupt occurring during this time would continue to stay latched and interrupt the CPU when global interrupts are re-enabled.