MSPM33C321A: Clarification Required on Memory Architecture and Security Configuration

Hi,

On MSPM33C321A, Flash security is controlled by two layers:

1. Layer 1 — GSC (Global Security Controller): Controls hardware-level Flash bank security attributes. 
2. Layer 2 — SAU: Marks the address range as Non-Secure to the CPU.
   1. The Cortex-M33 has a hardware SAU with up to 8 programmable regions. Each region is tagged as:
      1. Secure — only accessible from secure code
      2. Non-Secure (NS) — accessible by non-secure code
      3. Non-Secure Callable (NSC) — a gateway: non-secure code can call into it, but it's still physically secure flash; used for veneer functions
   2. Everything not covered by an SAU region defaults to Secure
   3. Reference example: examples/security/gpio_toggle/gpio_toggle_secure/LP_MSPM33C321A/, you can go through partition.h file

In security examples provided in SDK we have partitioned the flash memory:

1. Flash (0x0000_0000 – 0x0000_FFFF): Secure (secure app code)
2. Flash (0x0001_0000 – 0x0001_FFFF): Non-Secure (NS app code)
3. Flash (0x1000_F800 – 0x1000_FFFF): NSC gateway (veneer functions)

you can choose to modify the example change the defines in config.h NON_SECURE_APP0_START (0x10000) to (0x0) and LEN to 1MB.

Jayant Saxena said:

What specific settings or configurations are required to achieve this?

I would like to know your use case here? 

1. No TrustZone needed: If your application does not require separating Secure and Non-Secure assets, you do not need to configure SAU or GSC at all. The MSPM33C321A will start in Secure state and your entire application runs in Secure state  all Flash, SRAM, and peripherals are accessible without restriction. This is the simplest and recommended approach for applications not using TrustZone.

2. TrustZone partitioning with large NS region: If you are using TrustZone (e.g., to protect cryptographic keys, a secure bootloader, or
privileged peripherals) and want the majority of Flash to be Non-Secure, a small Secure partition is still required at boot since the M33 core always starts in Secure state. The Secure code configures SAU/GSC and then transfers execution to the NS application. Refer to examples/security/gpio_toggle/ in the SDK for a working example of this pattern.

Jayant Saxena said:

What factors determine whether the M33 core operates in Secure or Non-Secure state?

The Cortex-M33 security state is defined by ARM architecture and is determined by the memory attribute of the address being executed:

• Core always starts in Secure state after reset. - If the PC is in a Secure-attributed region → core is in Secure state.
• If the PC is in a Non-Secure-attributed region → core is in Non-Secure state.
• Transitions between states happen via dedicated branch instructions (BXNS/BLXNS) or exception handling.

For complete details, please refer to the https://developer.arm.com/documentation/100230/latest.

Jayant Saxena said:

Execution Flow Scenario

• Consider the following scenario:
  • The LED blink code is placed entirely in Non-Secure Flash.
  • After flashing, the core is expected to start execution in Secure state.
• In this case, since the entire application resides in Non-Secure Flash, how does execution still proceed successfully?

It is not possible to run code placed only in Non-Secure Flash without a Secure region handling the reset and handoff.

The core always resets in Secure state. Even if the application code resides entirely in Non-Secure Flash, a Secure application must exist to configure the SAU/GSC and explicitly hand off execution to the Non-Secure application via BXNS. Without a Secure region, the Non-Secure application cannot execute.

Jayant Saxena said:

When SAU is left unconfigured (i.e. SAU->CTRL = 0), does this imply that memory regions are treated as Non-Secure by default, based on the IDAU configuration?

The final security level uses both the SAU configuration and the IDAU configuration. For determining a section of memory's security level, take the higher security level between the SAU and IDAU. For information on how the IDAU is configured please see the CPU section of the MSPM33C3-Series 160MHz Microcontrollers Technical Reference Manual.

Jayant Saxena said:

Is it mandatory to define a Secure region from which execution begins?

Execution begins at 0x10000000,  The core always resets in Secure state, and since Secure state can access all memory regions (Secure, NSC,
and Non-Secure), if the entire Flash is configured as Non-Secure, the core will still reset, fetch the vector table, and execute the application without any fault — because it is running in Secure state.

The Secure region is only required if you intentionally want to restrict certain code or data from being accessible in Non-Secure state as part of a TrustZone partitioning scheme. If TrustZone partitioning is not needed, simply do not configure the SAU or GSC and run the entire application in Secure state.

Jayant Saxena said:

If so, why does code placed entirely in the Non-Secure region still execute correctly?

So 0x10000000 and 0x00000000 are the same physical Flash, just aliased — the 28th bit being 1 makes it NSC per IDAU, and the 28th   bit being 0 makes it NS per IDAU.

The reset vector is fetched from 0x10000000 (NSC alias), Secure state can access it freely, execution proceeds correctly.

But if the customer links their application to 0x00000000 (NS alias) instead of 0x10000000 (NSC alias), the IDAU would attribute it as Non-Secure  and execution would still work because the core is in Secure state which can access NS regions as well.

Secure state can access all memory regions (S, NSC, and NS), which is why code placed entirely in  Non-Secure Flash executes correctly, the core never leaves Secure state unless explicitly instructed to via BXNS.

Hi Utkarsh,

Thank you for the detailed clarification on the topics we discussed earlier—it was very helpful.

I just want to reconfirm our understanding before proceeding, to ensure we are aligned on the configuration:

1. The entire application code will reside within the secure region, with no portions executing in the non-secure domain.
2. No SAU configuration will be performed explicitly, i.e., SAU → CTRL will remain set to 0, and we will rely on the default memory attribution.
3. NTZ_FreeRTOS will be used in this setup alongside the above configuration.

Given this combination, could you please confirm if everything is expected to function correctly, or if there are any potential limitations, dependencies, or considerations we should be aware of?

Looking forward to your confirmation.