Similar to PIE Vector Table Swap, LS0
and LS1 physical RAM memory blocks can also be swapped. The memory architecture is
similar to PIE vector table swap, and is shown in Figure 3-20. By default, physical Block 1 is assigned to addresses 0x8000-0x87FF (that is,
the address range for LS0), and physical Block 2 is assigned to addresses
0x8800-0x8FFF (that is, the address range for LS1). By configuring
LFUConfig.LS01Swap = 1, user application code can execute a swap, where physical
Block 2 is now assigned to addresses 0x8000-0x87FF (that is, the address range for
LS0), and physical Block 1 is now assigned to addresses 0x8800-0x8FFF (that is, the
address range for LS1).
If physical
memory Block 1 contains function pointers for the current firmware, the same
relative locations in physical memory Block 2 can be populated with function
pointers for the new firmware prior to LFU switchover. During LFU switchover, a
simple swap operation is initiated by user application code, and this operation
takes just 1 CPU clock cycle. This allows user application code to always have
function pointers in LS0, yet have two different physical blocks that can map to the
LS0 address range.
For example, if current firmware
contains 10 function pointers present at the start of Block 1 (LS0 address space).
If the new firmware contains the same 10 function pointers that now need to be
updated, user application code can place these at the start of Block 2 (LS1 address
space) prior to LFU switchover. During LFU switchover, user application code
executes a LS0/LS1 RAM memory swap, where the physical RAM block previously mapped
to the LS1 address space can now be mapped to the LS0 address space, and hence can
be used seamlessly for function pointer addressing for the new firmware.
The register bit LFUStatus.LS01Swap
provides the status of LS0/LS1 RAM memory swap.
Additional points pertaining to
LS0/LS1 RAM memory swap are:
- LFU registers can be accessed
from both CPU and CLA.
- Only LS0 and LS1 blocks can be
swapped. LS2 to LS7 blocks cannot be swapped.
- LS0 and LS1 blocks have parity
protection. Address parity is computed based on the physical address and hence
the address does not change based on the memory swap.
- A number of LSx RAM registers are
available to the user application code to configure options such as select
(LSxMSEL.MSEL_LS0, LSxMSEL.MSEL_LS1), fetch protect (LSxACCPROT0.FETCHPROT_LS0,
LSxACCPROT0.FETCHPROT_LS1), write protect (LSxACCPROT0.CPUWRPROT_LS0,
LSxACCPROT0.CPUWRPROT_LS1), CLA program memory LSxCLAPGM.CLAPGM_LS0,
LSxCLAPGM.CLAPGM_LS1). These register bits indicate the status of the memory
block that is deemed as LS0 (CPU address 0x8000 to 0x87FF) and LS1 (CPU address
0x8800 to 0x8FFF) at any point of time. When a LS0/LS1 RAM memory swap occurs,
the corresponding control/status bits also automatically swap.
- Service all pending errors
(access violation and parity) associated with the memory before initiating a
LS0/LS1 RAM memory swap.
- LS0/LS1 RAM memory swap shall be
initiated only after completion of RAM initialization for both LS0 and LS1
memories (LSxINITDONE.INITDONE_LS0 = 1 and LSxINITDONE.INITDONE_LS1 = 1).
- LS0/LS1
RAM memory swap shall not be initiated when RAM-test (LSxTEST.TEST_LS0 = 1 or
LSxTEST.TEST_LS1 = 1) is in progress for LS0 or LS1 blocks.
- With DCSM security on the device,
in general, LS0 and LS1 RAM blocks can be assigned to different security zones.
However, with LS0/LS1 RAM memory swaps, different physical RAM blocks can get
mapped to the same address space. Application software shall therefore make sure
that both LS0 and LS1 have the same security settings (for example, zone, EXE
protection), if there is a plan to implement LS0/LS1 RAM memory swap. Hardware
logic is implemented on the device to prevent swap of LS0 and LS1 if the blocks
have different security configurations.
- To prevent security
vulnerabilities, LS0/LS1 RAM memory swap is not allowed if the memory swap is
initiated by code from a different zone. For example:
- if LS0 and LS1 are part
of Zone1, the swap is not allowed if the code that initiates the swap
resides in Zone2 or unsecure zone
- if LS0 and LS1 are part
of Zone2, the swap is not allowed if the code that initiates the swap
resides in Zone1 or unsecure zone
- if LS0 and LS1 are part
of the same zone that is unsecure, the swap is allowed in all cases
irrespective of where the code that initiates the swap resides
- if LS0 and LS1 are part
of the same zone and is unlocked, the swap can be initiated from code
residing anywhere (including from the debugger)
- Once the swap is initiated, the
swap happens in the next cycle, subject to the swap meeting the security
requirements previously mentioned. After initiation of a swap, application
software shall check if the swap was correctly configured by checking the
LFUStatus.LS01Swap status register. Consistency between LFUStatus.LS01Swap and
LFUConfig.LS01Swap helps determine if the swap was correctly configured. If
LFUStatus.LS01Swap does not match LFUConfig.LS01Swap, LFUConfig.LS01Swap needs
to be cleared by user application code.