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.