The key considerations when creating LFU-ready firmware are operational continuity during LFU, and LFU switchover time. These two are closely related. Operational continuity is achieved through the persistence of state, keeping existing static and global variables in RAM at the same addresses between firmware versions, and avoiding re-initialization of those variables when the new firmware is activated. LFU Compiler support enables this.

Activating the new firmware involves branching to the LFU entry point of the new firmware, executing the compiler's LFU initialization routine, arriving inside the main() of the new image, and performing additional initialization. This is where interrupts are briefly disabled, and initialization that needs interrupts to be disabled is performed (for example, Interrupt vector updates, function pointer updates), before interrupts are re-enabled. This last time interval is defined as the LFU switchover time.

LFU is simplified when there is hardware support to swap Flash banks, where either Flash bank can be mapped to a fixed address space, considered the Active bank. The Inactive bank is mapped to a different address space and is the bank that is updated. C2000™ MCUs do not currently support Flash bank swap, so active and inactive banks need to be tracked, and you need to use the linker command file to create application firmware targeted to specific banks.

Function pointers and Interrupt vectors need to be re-initialized inside main(), since their locations are different between Flash banks. C2000 MCUs support a large number of interrupt vectors (typically 192), so it is not practical to re-initialize all of them. Usually, only a few are used, and the rest are assigned to a default vector. LFU-specific hardware features (Interrupt vector swapping, RAM block swapping) enable a significant reduction in the LFU switchover time.