SLAAE29A January   2023  – December 2025 MSPM0C1105 , MSPM0C1106 , MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G1518 , MSPM0G1519 , MSPM0G3105 , MSPM0G3106 , MSPM0G3106-Q1 , MSPM0G3107 , MSPM0G3107-Q1 , MSPM0G3505 , MSPM0G3506 , MSPM0G3506-Q1 , MSPM0G3507 , MSPM0G3507-Q1 , MSPM0G3518 , MSPM0G3518-Q1 , MSPM0G3519 , MSPM0G3519-Q1 , MSPM0L1105 , MSPM0L1106 , MSPM0L1227 , MSPM0L1227-Q1 , MSPM0L1228 , MSPM0L1228-Q1 , MSPM0L1303 , MSPM0L1304 , MSPM0L1304-Q1 , MSPM0L1305 , MSPM0L1305-Q1 , MSPM0L1306 , MSPM0L1306-Q1 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346 , MSPM0L2227 , MSPM0L2227-Q1 , MSPM0L2228 , MSPM0L2228-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
    1. 1.1 Key Concepts
    2. 1.2 Goals of Cybersecurity
    3. 1.3 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 Boot Flow
    6. 2.6 User-Specified Security Policies
      1. 2.6.1 Boot Configuration Routine (BCR) Policies
        1. 2.6.1.1 Serial Wire Debug Related Policies
          1. 2.6.1.1.1 SWD Security Level 0
          2. 2.6.1.1.2 SWD Security Level 1
          3. 2.6.1.1.3 SWD Security Level 2
        2. 2.6.1.2 Bootstrap Loader (BSL) Enable/Disable Policy
        3. 2.6.1.3 Flash Memory Protection and Integrity Related Policies
          1. 2.6.1.3.1 Locking the Application (MAIN) Flash Memory
          2. 2.6.1.3.2 Locking the Configuration (NONMAIN) Flash Memory
          3. 2.6.1.3.3 Verifying Integrity of Application (MAIN) Flash Memory
        4. 2.6.1.4 Bootstrap Loader (BSL) Security Policies
          1. 2.6.1.4.1 BSL Access Password
          2. 2.6.1.4.2 BSL Read-out Policy
          3. 2.6.1.4.3 BSL Security Alert Policy
      2. 2.6.2 Customer Secure Code (CSC) Security Policies
        1. 2.6.2.1 CSC Enforced Bankswap
        2. 2.6.2.2 CSC Enforced Firewalls
        3. 2.6.2.3 CSC Key Write to KEYSTORE
      3. 2.6.3 Configuration Data Error Resistance
        1. 2.6.3.1 CRC-Backed Configuration Data
        2. 2.6.3.2 16-bit Pattern Match for Critical Fields
  6. 3Secure Boot
    1. 3.1 Secure Processing Environment Isolation
    2. 3.2 Customer Secure Code (CSC)
      1. 3.2.1 Secure Boot Flow
      2. 3.2.2 Flash Memory Map
      3. 3.2.3 Features
        1. 3.2.3.1 CMAC Acceleration
        2. 3.2.3.2 Asymmetric Verification
        3. 3.2.3.3 KEYSTORE and Firewall
        4. 3.2.3.4 CSC Performance
      4. 3.2.4 Quick Start Guide
        1. 3.2.4.1 Environment Setup
        2. 3.2.4.2 Step by Step Guidance
        3. 3.2.4.3 CSC NONMAIN Configuration
        4. 3.2.4.4 Customize Changes on CSC Example
    3. 3.3 Boot Image Manager (BIM)
      1. 3.3.1 Secure Boot Flow
      2. 3.3.2 Flash Memory Map
      3. 3.3.3 Quick Start Guide
  7. 4Secure Storage
    1. 4.1 Flash Write Protection
    2. 4.2 Flash Read-Execute Protection
    3. 4.3 Flash IP Protection
    4. 4.4 Data Bank Protection
    5. 4.5 Secure Key Storage
    6. 4.6 SRAM Protection
    7. 4.7 Hardware Monotonic Counter
  8. 5Cryptographic Acceleration
    1. 5.1 Hardware AES Acceleration
      1. 5.1.1 AES
      2. 5.1.2 AESADV
    2. 5.2 Hardware True Random Number Generator (TRNG)
  9. 6FAQ
  10. 7Summary
  11. 8References
  12. 9Revision History

6 FAQ

  1. What is the Root-of-Trust in MSPM0 CSC solution?

    A: The Root-of-Trust includes immutable TI ROM boot-code and static write protected CSC region. They are immutable after correctly NONMAIN configuration. See CSC NONMAIN Configuration for details.

  2. Does CSC handle firmware update process?

    A: No. CSC only verifies the application firmware that has been placed in a certain flash address in advance but does not handle firmware update process (bootloader) and not care how the firmware is loaded to the flash.

  3. What is the timing feature of different algorithms in CSC solution?

    A: See CSC Performance for details.

  4. When I try to download new firmware to a device that is running application with CSC or bank swap, why CCS/Uniflash reports erase error?

    A: When bank swap is enabled, the logic low bank gets read-execute privileges and loses write/erase privileges. The other bank (logic high bank) is readable and writeable but not executable. When CCS or Uniflash try to download a firmware starts from address 0x0000, it will report erase error since logic low bank address is not erasable. You could update your firmware starting from high bank address, or just take a factory reset before load program.

  5. Why a power cycle or NRST reset is needed after downloading CSC example?

    A: The CSC example includes NONMAIN configurations to enable CSC. The NONMAIN configurations take effect during boot-code, and only a BOOTRST (or higher level) reset could make MSPM0 get back to ROM boot-code.

  6. How could I change application program start address in CSC?

    A: See Customize Changes on CSC Example for details.

  7. Which output format should I choose for CSC, application image and NONMAIN region output?

    A: The .txt/.bin/.hex format could be used for firmware updated. NONMAIN configuration should be programmed together with CSC and do not update NONMAIN region along with application firmware. See Step by Step Guidance for guidance.

  8. Why does CCS report post-build fail error when building customer_secure_sample_image?

    A: Please check whether you have successfully set Python environment before building CSC sample image example. And make sure the CSC example is in the same workspace with CSC sample image example.

  9. Is there secret key storage region for asymmetric encryption/decryption in application program?

    A: MSPM0 devices only provide symmetric secret key storage (KEYSTORE) for the AES engine. The asymmetric encryption/decryption algorithm key (such as ECDSA public key) is stored in a SECRET region. This SECRET region could only be accessed in privileged state (pre-INITDONE) and is read protected & write protected by firewall when running application.

  10. How could I give the application address in linker file?

    A: In bank swap enabled configuration, an application program should always be built with a given logic low bank address. Take MSPM0G3519 as an example, the address range defined in linker file (.cmd in CCS) should be 0x00000~0x40000. But when updating the application firmware, the firmware needs to be loaded to the logic high bank address since the program is running in logic low bank and only the logic high bank has read-write access.

  11. What if I want to define my own application image format?

    A: Currently SDK CSC example is using the signing tool imgtool provided by MCUBOOT to generate application image with e.g. header and signature information. Users could define their own image format, but they need to achieve the parsing program in CSC for their own defined image format.

  12. What if I want to use symmetric approach only for secure boot?

    A: Users could use AES-CMAC for symmetrical image verification in MSPM0 devices with AESADV supported, see Platform Security Enablers for details. Make sure the AES key stored in MCU has been aligned with the image vendor in advance by a secure way.