SDAA473 November   2026 MSPM33C321A , MSPM33C321A-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
    1. 1.1 Security Concept
    2. 1.2 Key Concepts
  5. 2TrustZone Architecture
    1. 2.1 MSPM33 Family Overview
    2. 2.2 TrustZone Feature
      1. 2.2.1 Security States – Secure, Non-secure, Non-secure Callable
      2. 2.2.2 First Security Attribute Define – SAU and IDAU
      3. 2.2.3 Second Security Attribute Define – Global Security Controller
      4. 2.2.4 Security Attribute with TrustZone® and GSC
      5. 2.2.5 Secure and Non-secure Debug Authentication
    3. 2.3 TrustZone® Software Development
  6. 3Develop TrustZone Based Application
    1. 3.1 Device Configuration
      1. 3.1.1 NONMAIN FLASH
        1. 3.1.1.1 Security and Privilege Configuration on FLASH
        2. 3.1.1.2 Other Configurations in NONMAIN FLASH
        3. 3.1.1.3 Configure NONMAIN FLASH in the Sysconfig
    2. 3.2 Develop Secure Application
      1. 3.2.1 Project Dependency
        1. 3.2.1.1 Structure of Secure Application Example
      2. 3.2.2 SAU and IDAU Configuration
        1. 3.2.2.1 Configure SAU in the Project
      3. 3.2.3 Global Security Controller Configuration
        1. 3.2.3.1 Configure GSC in the Sysconfig
        2. 3.2.3.2 Other Configurations in GSC
      4. 3.2.4 Defining Functions as Secure and Non-Secure
        1. 3.2.4.1 Define Non Secure Callable function in the Project
      5. 3.2.5 Code Implementation on Secure Application
        1. 3.2.5.1 Configure .cmd file to assign memory
        2. 3.2.5.2 Secure Application
        3. 3.2.5.3 Secure Interrupt and Non-secure Interrupt
        4. 3.2.5.4 Branch to Non-secure Application
    3. 3.3 Develop Non-Secure Application
      1. 3.3.1 Project Dependency
        1. 3.3.1.1 Structure of Non-secure Application Example
      2. 3.3.2 Code Implementation on Non-secure Application
        1. 3.3.2.1 Configure .cmd file to assign memory
        2. 3.3.2.2 Non-secure Application and NSC Function Call
  7. 4Evaluate TrustZone Based Application
    1. 4.1 Environment Setup
    2. 4.2 Load Secure and Non-secure Images Together
      1. 4.2.1 Step 1: Build the Non-Secure Application
      2. 4.2.2 Step 2: Programming the full.txt File
    3. 4.3 Load Secure and Non-secure Images separately
      1. 4.3.1 Step 1: Build the Non-Secure Application
      2. 4.3.2 Step 2: Programming the Non-Secure Application
      3. 4.3.3 Step 3: Build the Secure Application
      4. 4.3.4 Step 4: Programming the Secure Application
    4. 4.4 Debug and Evaluate the Example
      1. 4.4.1 Add Symbols in the Debug
      2. 4.4.2 Observe Results with Free Run
      3. 4.4.3 Add Breakpoints to Observe the Process
  8. 5FAQ
    1. 5.1 How to Modify the Range of S/NS SRAM
    2. 5.2 How to Modify the Range of S/NS FLASH
    3. 5.3 How to Modify the Security Attribute on Peripherals
  9. 6Summary
  10. 7References

3.2.5.3 Secure Interrupt and Non-secure Interrupt

Both secure application and non-secure application have its own interrupt vector table, so user can define IRQ handlers for both secure state and non-secure state, and appropriately the linker will place them. Please check '.intvecs' in cmd file of both applications.

Non-secure interrupts can still be serviced when executing a Secure function. Transitions between security states take place automatically during exception handling.

Armv8-M architecture definite the register ITNS( interrupt target non-secure state) in NVIC, which allows users to define whether the interrupt should target a secure state or non-secure state.

As shown in the Table 3-6, some IRQs are configurable, which means user can configure them to be handled by either secure handler or NS handler. And some of IRQs are banked, which means we can have two different IRQ handlers for S and NS, and set the ITNS register to redirect the interrupt to the appropriate handler.

For exception prioritisation. user may want to guarentee that critical secure exceptions are always given higher priority than NS exceptions. Secure exception priority can be enabled by setting AIRCR.PRIS.

Table 3-6 Configurability for interrupts and exceptions available in an Armv8-M processor
Exception number Exception type Type Default target type Note
1 Reset Secure only Secure -
2 NMI Configurable Secure Configurable by AIRCR.BFHFMNINS bit. However, AIRCR.BFHFNMINS bit should be set to 1 only when Secure state is unused and calling Secure functions or Secure exceptions should be strictly blocked.
3 HardFault Configurable Secure Configurable by AIRCR.BFHFMNINS bit. However, AIRCR.BFHFNMINS bit should be set to 1 only when Secure state is unused and calling Secure functions or Secure exceptions should be strictly blocked
4

MemManage

Fault

 Banked N/A -
5 BusFault Configurable Secure Configurable by AIRCR.BFHFMNINS bit. However, AIRCR.BFHFNMINS bit should be set to 1 only when Secure state is unused and calling Secure functions or Secure exceptions should be strictly blocked
6 UsageFault Banked N/A -
7 SecureFault Secure only Secure -
11 SVC Banked N/A -
12

Debug

monitor

 Configurable Depends on External Debug authentication signals If Secure debug is enabled in the debug authentication interface, it will target the Secure state, else Debug Monitor exception targets Non-secure state
14 PendSV Banked N/A
15 SysTick

Banked or

Configurable

 Banked if two SysTick timers are available. If there is only one SysTick timer, by default the SysTick exception targets Secure state. When one SysTick timer is used, then ICSR.STTNS bit is used to configure the target state of SysTick. Two SysTick timers are always present on Mainline CPUs like Cortex-M33 and greater.
16-495

External

interrupts

 Configurable Secure Using NVIC_ITNS register the interrupts can be configured to either Secure or Non-secure state.

For more information, please refer to the MSPM33 C3-Series 160MHz Microcontrollers technical reference manual.

In the example, user can use NVIC_SetTargetState() to set configurable IRQ to non-secure. User can also use NVIC_GetTargetState() to check the IRQ S/NS status.