A simplified representation of the LFU
switchover is shown in Figure 3-20, and is
described in the following steps:
- In typical systems, a host –
typically a PC or another MCU, initiates 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, or PIE vectors or function pointers can get added or removed between
firmware versions, the 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, the 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, the 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, at an appropriate
time (depicted as LFU Switchover – waiting for appropriate time), the 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), the 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).