SLUUDG7A December   2025  – November 2026 MSPM33C321A , MSPM33C321A-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Overview of Security Functionality
    1. 1.1 Terminology
    2. 1.2 Platform Security Enablers
  5. 2Device Security Model
    1. 2.1 Device Identity
    2. 2.2 Initial Conditions at Boot
    3. 2.3 Boot Configuration Routine (BCR)
    4. 2.4 Bootstrap Loader (BSL)
    5. 2.5 Lifecycle Management
      1. 2.5.1 Lifecycle Transitions
    6. 2.6 Boot Service
    7. 2.7 Boot Flow
    8. 2.8 User-Specified Security Policies
      1. 2.8.1 Boot Configuration Routine (BCR) Policies
        1. 2.8.1.1 Serial Wire Debug Related Policies
          1. 2.8.1.1.1 No Restrictions Scenario
          2. 2.8.1.1.2 Custom Restrictions Scenario
          3. 2.8.1.1.3 Fully Restricted Scenario
        2. 2.8.1.2 Bootstrap Loader (BSL) Enable/Disable Policy
        3. 2.8.1.3 Flash Memory Protection and Integrity Related Policies
          1. 2.8.1.3.1 Locking the Application (MAIN) Flash Memory
          2. 2.8.1.3.2 Locking the Configuration (NONMAIN) Flash Memory
          3. 2.8.1.3.3 Security and Privilege Protection on Application (MAIN, DATA) Flash Memory
          4. 2.8.1.3.4 Verifying Integrity of Application (MAIN) Flash Memory
      2. 2.8.2 Bootstrap Loader (BSL) Security Policies
        1. 2.8.2.1 BSL Access Password
        2. 2.8.2.2 BSL Read-out Policy
        3. 2.8.2.3 BSL Security Alert Policy
      3. 2.8.3 Customer Secure Code (CSC) Security Policies
        1. 2.8.3.1 CSC Enforced Bankswap
        2. 2.8.3.2 CSC Key Write to KEYSTORE
      4. 2.8.4 Configuration Data Error Resistance
        1. 2.8.4.1 CRC-Backed Configuration Data
          1. 2.8.4.1.1 BCR Configuration CRC Fail Handling
          2. 2.8.4.1.2 TI Factory Trim Data CRC Fail Handling
        2. 2.8.4.2 BSL Configuration CRC Fail Handling
        3. 2.8.4.3 16-bit Pattern Match for Critical Fields
  6. 3Secure Boot
    1. 3.1 MCUBoot
    2. 3.2 ROM-based Secure Boot
      1. 3.2.1 ROM-based Secure Boot Flow
      2. 3.2.2 Customer Key Storage
        1. 3.2.2.1 Key Revocation Using the DSSM
        2. 3.2.2.2 Key Revocation Using the Firmware Update
      3. 3.2.3 Anti‑rollback Protection
    3. 3.3 CSC-based Secure Boot
      1. 3.3.1 CSC-based Secure Boot Flow
      2. 3.3.2 FLASH Memory Map
      3. 3.3.3 CSC Key Storage
        1. 3.3.3.1 Key Storage for CSC-based Secure Boot
        2. 3.3.3.2 KEYSTORE for AES
      4. 3.3.4 Bank Swap
      5. 3.3.5 CSC Protection
    4. 3.4 Two Stage Secure Boot
      1. 3.4.1 Two Stage Secure Boot Flow
  7. 4Secure Execution Environment
    1. 4.1 TrustZone
      1. 4.1.1 Implementation Defined Attribution Unit
      2. 4.1.2 Security Attribution Unit
        1. 4.1.2.1 Defining a Region as Secure
      3. 4.1.3 TrustZone Software Development
        1. 4.1.3.1 Defining Functions as Secure and Non-secure
    2. 4.2 Memory Protection Unit
      1. 4.2.1 TrustZone and MPU
    3. 4.3 Global Security Controller
      1. 4.3.1 GSC Memory Configuration
        1. 4.3.1.1 Security Exceptions Through the GSC and SAU
        2. 4.3.1.2 Privilege Exceptions With GSC and MPU
  8. 5Secure Storage
    1. 5.1 Write Erase Protection
      1. 5.1.1 Global Security Controller Configuration on WEP
      2. 5.1.2 NONMAIN FLASH Configuration on WEP
    2. 5.2 FLASH Hide Protection
      1. 5.2.1 Global Security Controller Configuration on HDP
    3. 5.3 Secure Key Storage
    4. 5.4 Data Integrity Verification
    5. 5.5 Secure and Privilege Protection
    6. 5.6 Hardware Monotonic Counter
  9. 6Security Modules
    1. 6.1 AESADV
      1. 6.1.1 AES Overview
      2. 6.1.2 AES Usage
        1. 6.1.2.1 Configuration
        2. 6.1.2.2 Setup
        3. 6.1.2.3 Operation
    2. 6.2 Keystore
      1. 6.2.1 Overview
      2. 6.2.2 Keystore Usage
        1. 6.2.2.1 Configuration
        2. 6.2.2.2 Setup
        3. 6.2.2.3 Operation
    3. 6.3 SHA2
      1. 6.3.1 SHA Introduction
        1. 6.3.1.1 SHA Features
      2. 6.3.2 SHA Performance
      3. 6.3.3 SHA Usage
        1. 6.3.3.1 Configuration
        2. 6.3.3.2 Setup
        3. 6.3.3.3 Operation
    4. 6.4 PKA
      1. 6.4.1 PKA Introduction
        1. 6.4.1.1 PKA features
      2. 6.4.2 PKA Usage
        1. 6.4.2.1 Configuration
        2. 6.4.2.2 Setup
        3. 6.4.2.3 Operation
    5. 6.5 PQC
      1. 6.5.1 ML-DSA
        1. 6.5.1.1 ML-DSA Introduction
        2. 6.5.1.2 ML-DSA Usage
          1. 6.5.1.2.1 Configuration
          2. 6.5.1.2.2 Setup
          3. 6.5.1.2.3 Operation
  10. 7Revision History

3.3.4 Bank Swap

User can enable bank swap in CSC-based secure boot by configuring BOOTCFG2.FLASHBANKSWAPPOLICY field in NONMAIN FLASH. Bank swap behavior happens in the CSC stage, while the behavior goes into effect after the device issues INITDONE.

Note: BOOTCFG2.FLASHBANKSWAPPOLICY field in NONMAIN FLASH is default disabled. When enable this field, bank swap is only enabled for CSC-based secure boot, and there is no bank swap for ROM-based secure boot. However, depending on this field, ROM-based secure boot check and verify standalone APP(when bank swap disabled) or dual APP(when bank swap enabled). To modify this field, please refer to MSPM33 NONMAIN Flash Memory Configuration Guide .

In bank swap method, the actual firmware does not move between physical locations - instead, the address of two banks are swapped. As shown in Figure 3-8, there is a physical bank 0 (PB0) and physical bank 1 (PB1). These banks can switch addresses depending on the bank swap configuration.

To indicate the address swapping, we can define two logical banks(LB) that map to physical bank 0 or physical bank 1. Before INITDONE Logical Bank 0 always maps to address PB0, and Logical Bank 1 maps to PB1. However, depending on the bank swap execution, post INITDONE LB0 can map to PB0 or PB1.

In general with bank swap feature enabled, CSC always start APP in LB0. So if the APP being executed locates at PB0, CSC configures bank swap not happened by setting FLBANKSWP.USEUPPER to 0h(default), and LB0 maps to PB0. If the APP being executed locates at PB1, CSC configures bank swap happened by setting FLBANKSWP.USEUPPER to1h(default), and LB0 maps to PB1.

Note: Since code only executes from logical bank 0, compile all code so that the code runs from logical bank 0. Thus, if the CSC is mapped from 0x0000 - 0x47FF and one application image mapped from 0x4800 onward, then compile each application image with respect to 0x4900 (0x100 trailer, then application interrupt vectors placed at 0x4800 + 0x100 = 0x4900), even if the application image is written to logical bank 1 at effective physical address.