A simplified representation of the LFU
switchover is shown in Figure 3-16, and is
described in the following steps:
- In typical systems, a host –
typically a PC or another MCU, will initiate 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 may move
existing PIE vectors and function pointers to new locations between firmware
versions, or PIE vectors or function pointers could 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 would need 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, at a suitable time (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).