A simplified representation of the LFU switchover is shown in Figure 3-18 and is described in the following steps:
- In typical systems, a host – typically a PC or another MCU, initiates the LFU (depicted as LFU Request) on the application MCU (in this case, the C2000 MCU) that is executing the real-time control application. This initiates the Flash Program sequence in the application MCU. This runs as a background process even as the application MCU continues executing firmware (depicted as Firmware - 1).
- Since the compiler can move existing PIE vectors and function pointers to new locations between firmware versions, PIE vectors or function pointers can get added or removed between firmware versions. User application code needs to manage these properly and efficiently during LFU. In the absence of Flash remapping (where different Flash memory banks can be mapped to the same address), PIE vector table remapping, that is “swapping” and RAM memory block swapping are features supported on the device. Without swapping, user application code needs to individually update each PIE vector and each function pointer, adding valuable cycles to the LFU switchover time. With swapping, prior to LFU switchover, user application code can populate a different PIE vector table (depicted as PIE Swap Memory Update) and a different LS RAM region (depicted as LSx Swap Memory Update).
- When complete (depicted as LFU Switchover – waiting for appropriate time), user application code initiates the transition to new firmware. Once the compiler LFU initialization routine completes and transfers execution to the new application (depicted as Firmware – 2), user application code needs to perform necessary initialization before the new application can begin running. Since PIE vectors and function pointers have already been populated in the “swap” locations, all that is required is a PIE vector table swap and LSx RAM Memory Swap (depicted as PIE Vector Swap, LSx Memory Swap).