ARM Cortex-M33 MPC Configuration for SSRAM1 and SSRAM3 on MPS2+ AN505

The ARM Cortex-M33 processor, as implemented on the MPS2+ board with the AN505 IoT Kit, utilizes Memory Protection Controllers (MPCs) to manage secure and non-secure memory regions. The MPC configuration is critical for ensuring proper memory partitioning, especially in TrustZone-enabled systems. The discussion revolves around the configuration of MPCs for SSRAM1 and SSRAM3, which are mapped to both secure and non-secure address spaces. The primary confusion arises from the block size calculations, block index assignments, and the interpretation of the Look-Up Table (LUT) values. This guide will dissect the configuration process, clarify the misunderstandings, and provide a step-by-step approach to correctly configure the MPCs for SSRAM1 and SSRAM3.

Misalignment in Block Size Calculations and LUT Index Assignments

The first point of confusion lies in the block size calculations and the assignment of the LUT index for SSRAM3. SSRAM3 is a 2MB memory region with a block size of 64KB, which implies that there should be 32 blocks (2048KB / 64KB = 32). Each block is represented by a single bit in the LUT, and since the LUT is 32 bits wide, only one LUT entry is required to configure all 32 blocks. However, the example code sets the BLK_IDX to 1, which is incorrect. The BLK_IDX should be set to 0 because the LUT index starts at 0, and only one LUT entry is needed to cover all 32 blocks of SSRAM3.

The second point of confusion is in the comment for SSRAM1, where it states blk_cnt = 0x10. SSRAM1 is a 4MB memory region with a block size of 128KB, which implies that there should be 32 blocks (4096KB / 128KB = 32). The comment incorrectly states blk_cnt = 0x10, which corresponds to 16 blocks. This is likely a typographical error in the comment, as the actual calculation in the code is correct (0x200000U / blk_size), which results in 32 blocks. The comment should be corrected to reflect the accurate block count.

Correcting MPC Configuration for SSRAM1 and SSRAM3

To correctly configure the MPC for SSRAM1 and SSRAM3, the following steps should be taken:

Step 1: Verify Block Size and Block Count Calculations

For SSRAM1:

  • The total size of SSRAM1 is 4MB.
  • The block size is 128KB.
  • The number of blocks is calculated as 4096KB / 128KB = 32.
  • The LUT index should start at 0, and only one LUT entry is needed to configure all 32 blocks.

For SSRAM3:

  • The total size of SSRAM3 is 2MB.
  • The block size is 64KB.
  • The number of blocks is calculated as 2048KB / 64KB = 32.
  • The LUT index should start at 0, and only one LUT entry is needed to configure all 32 blocks.

Step 2: Correct the LUT Index Assignment

For SSRAM1:

  • The BLK_IDX should be set to 0, as only one LUT entry is needed.
  • The BLK_LUT value should be set to 0xFFFF0000UL to configure the first 16 blocks as non-secure and the remaining 16 blocks as secure.

For SSRAM3:

  • The BLK_IDX should be set to 0, as only one LUT entry is needed.
  • The BLK_LUT value should be set to 0xFFFFFFFFUL to configure all 32 blocks as non-secure.

Step 3: Update the Code with Correct Configuration

The corrected code for configuring SSRAM1 and SSRAM3 is as follows:

/* Configure unsecure code area MPSSSRAM1 (0x00200000 - 0x003FFFFF) */
// blk_max = IOTKIT_MPCSSRAM1->BLK_MAX;  /* = 0x1   */
// blk_cfg = IOTKIT_MPCSSRAM1->BLK_CFG;  /* = 0xC   */
// blk_size = 1UL << (blk_cfg + 5U);   /* = 0x20000 = 128 kB, 4MB / 128kB = 32 bit*/
// blk_cnt = 0x200000U / blk_size;    /* = 0x20  */
IOTKIT_MPCSSRAM1->CTRL &= ~(1UL << 8U);  /* clear auto increment */
IOTKIT_MPCSSRAM1->BLK_IDX = 0;      /* write LUT index */
IOTKIT_MPCSSRAM1->BLK_LUT = 0xFFFF0000UL; /* configure blocks. 0x00200000-0x003fffff: non-secure; 0x00000-0x1ffff: secure, alias to 0x10000000-0x101fffff*/

/* Configure unsecure data area MPSSSRAM3 (0x28200000 - 0x283FFFFF) */
// blk_max = IOTKIT_MPCSSRAM3->BLK_MAX;  /* = 0x1   */
// blk_cfg = IOTKIT_MPCSSRAM3->BLK_CFG;  /* = 0xB   */
// blk_size = 1UL << (blk_cfg + 5U);   /* = 0x10000 = 64 kB, 2MB / 64 kB = 32 bit */
// blk_cnt = 0x200000U / blk_size;    /* = 0x20  */
IOTKIT_MPCSSRAM3->CTRL &= ~(1UL << 8U);  /* clear auto increment */
IOTKIT_MPCSSRAM3->BLK_IDX = 0;      /* write LUT index */
IOTKIT_MPCSSRAM3->BLK_LUT = 0xFFFFFFFFUL; /* configure blocks */

Step 4: Validate the Configuration

After updating the code, it is essential to validate the configuration to ensure that the memory regions are correctly partitioned between secure and non-secure worlds. This can be done by writing test patterns to the memory regions and verifying that the access permissions are enforced as expected. Additionally, debugging tools such as JTAG probes can be used to inspect the MPC registers and confirm that the LUT values have been correctly set.

Step 5: Address Potential Timing Issues

In some cases, timing issues may arise due to the order in which the MPC registers are configured. It is recommended to insert memory barriers or use the DSB (Data Synchronization Barrier) instruction to ensure that all previous memory accesses are completed before proceeding with the next configuration step. This is particularly important when configuring multiple MPCs or when transitioning between secure and non-secure states.

Step 6: Document the Configuration

Finally, it is crucial to document the MPC configuration thoroughly. This documentation should include the block size calculations, LUT index assignments, and the rationale behind the chosen LUT values. This will aid in future debugging and maintenance of the system.

Conclusion

Configuring the MPC for the ARM Cortex-M33 on the MPS2+ AN505 board requires a clear understanding of the memory layout, block size calculations, and LUT index assignments. By following the steps outlined in this guide, you can ensure that the MPC is correctly configured for both SSRAM1 and SSRAM3, enabling proper memory partitioning between secure and non-secure worlds. Additionally, validating the configuration and addressing potential timing issues will help to avoid subtle hardware-software interaction problems that could lead to system instability or security vulnerabilities.

Similar Posts

ARM-Specific Tool Installation and RTL Rendering Issues on Corstone Platforms

ARM-Specific Tool Installation and RTL Rendering Issues on Corstone Platforms

BySystem on Chips

ARM-Specific Toolchain Installation Challenges for Corstone RTL Rendering The process of setting up ARM-specific tools for RTL (Register Transfer Level) rendering on Corstone platforms can be fraught with challenges, particularly when dealing with the installation and configuration of specialized toolchains. The primary issue revolves around the inability to locate and properly install the ARM-specific tool

Unexpected Cortex-M7 vs. Cortex-M3 FIR Filter Performance Discrepancy: Analysis and Solutions

Unexpected Cortex-M7 vs. Cortex-M3 FIR Filter Performance Discrepancy: Analysis and Solutions

BySystem on Chips

Cortex-M7 vs. Cortex-M3 FIR Filter Performance Discrepancy Overview The performance discrepancy between the Cortex-M7 and Cortex-M3 processors when executing a 128-tap FIR filter implementation has raised significant questions. The Cortex-M7, clocked at 600 MHz, demonstrates a runtime of 1260 microseconds for the FIR filter, while the Cortex-M3, clocked at 84 MHz, takes 44028 microseconds. This

ARMv9 RME Implementation and TZASC Functionality: Compatibility and Use Cases

ARMv9 RME Implementation and TZASC Functionality: Compatibility and Use Cases

BySystem on Chips

ARMv9 RME and TZASC: Coexistence and Functional Overlap The introduction of ARMv9 architecture brought significant advancements in security and memory management, particularly with the implementation of the Realm Management Extension (RME). RME introduces a new security state, the Realm state, which operates alongside the existing Secure and Non-secure states in ARM’s TrustZone technology. This new

Identifying and Handling L2 Cache ECC Single and Multiple Bit Errors in ARM Cortex-A53

Identifying and Handling L2 Cache ECC Single and Multiple Bit Errors in ARM Cortex-A53

BySystem on Chips

L2 Cache ECC Error Detection Mechanism in Cortex-A53 The ARM Cortex-A53 processor, a widely used core in embedded systems, implements Error Correction Code (ECC) mechanisms to ensure data integrity in its L2 cache. ECC is critical for detecting and correcting memory errors, which can occur due to various factors such as radiation, electrical noise, or

ARM Cortex-A35 EL3 to Non-Secure EL1 Transition Failure and Peripheral Access Issues

ARM Cortex-A35 EL3 to Non-Secure EL1 Transition Failure and Peripheral Access Issues

BySystem on Chips

ARM Cortex-A35 EL3 to Non-Secure EL1 Transition Failure The core issue revolves around the inability to successfully transition from Exception Level 3 (EL3) to non-secure Exception Level 1 (EL1) on an ARM Cortex-A35 processor operating in AArch64 mode. The user attempted to switch from EL3 to non-secure EL1 by configuring the Secure Configuration Register (SCR_EL3),

ARM Cortex-R52 MPU Configuration Conflict: Device vs. Normal Memory Type Mismatch

ARM Cortex-R52 MPU Configuration Conflict: Device vs. Normal Memory Type Mismatch

BySystem on Chips

ARM Cortex-R52 MPU Configuration Conflict: Device vs. Normal Memory Type Mismatch The ARM Cortex-R52 processor, designed for real-time and safety-critical applications, employs a Memory Protection Unit (MPU) to enforce memory access rules and attributes. One of the critical features of the MPU is its ability to define memory regions with specific attributes, such as Device

Leave a Reply

Your email address will not be published. Required fields are marked *