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

2.5.1 Lifecycle Transitions

During the life of the device, the state changes based on the current state of the device and the security settings that are applied.

The following is sequence of steps for transitioning from HS-FS to HS-KP.

  • DSSM command (DSSM_COMMAND_SECURE_KEY_PROVISIONING) shall be given by user to device.
  • Eight RoT public keys (six for secure boot and two for secure debug) is sent to the device.
  • ROM marks the device as HS-KP.

The following is sequence of steps for transition from HS-KP to HS-SE.

  • If the debug port is not locked, then application/CSC can be programmed using the debug port.
  • Alternatively invoke BSL to program the application
  • Program the signed CSC or application over BSL
  • Once ROM validates the CSC or application, the device is marked as HS-SE

The following is sequence of steps for transition from HS-KP/HS-SE to HS-FA.

  • DSSM command (DSSM_COMMAND_RMA) shall be given by user to device
  • If Combined certificate is received and validated then ROM Marks the device as HS-FA
  • Device goes to HS-FA Authenticated Flow

To convert the device to DCOM/BAD, user can send DSSM command (DSSM_COMMAND_CONVERT_BAD_DEVICE).

Note: Customer return flow Customers need to transition the device to HS-FA state from HS-KP / HS-SE before sending the device back to TI for failure analysis. Customer has the option to secure the different assets (for example, code, keys, and others.) by programming / erasing them. Be aware that erasing the content will restrict and limit the debug of some of the failures (for example, flash data retention failure cannot be debugged once the content is erased).