LFU is feasible when the device has
enough resources of various kinds – CPU bandwidth, Memory, and Peripheral
availability:
- CPU Bandwidth – The new firmware has to be transferred using a
communication peripheral and written to flash memory while the application is
still operating. This means CPU need to have enough available bandwidth to
support LFU.
- Memory – The non-volatile memory that is used here is Flash
memory. Flash read and write operations cannot be simultaneously performed on
the same Flash bank. However read and write operations can be simultaneously
performed on different Flash banks. Hence, the ideal scenario is for the device
to contain dual Flash banks. In devices with single Flash banks, LFU is
particularly challenging, but still feasible provided:
- The complete application code (or a portion of it that
controls the output(s) the user is interested in) and Flash APIs need to
run from RAM memory while the new firmware is updated to Flash. This
means there should be enough RAM memory that can be utilized.
- Some devices support Flash APIs in ROM; in those devices
the application code can run from RAM and Flash APIs can run from ROM
memory, thus reducing the RAM requirement.
- Peripheral Availability – A spare communication peripheral using
the new image can be transferred from the host to the device.
LFU is easier to implement in devices
with multiple Flash banks. In this document and the reference example, it is assumed
that the device has 2 Flash banks. The device considered is TMS320F28004x, which has
dual flash banks. Their address space is 64K x 16 each, with addresses ranging from
0x80000-0x8FFFF, and 0x90000-0x9FFFF.