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
2.6.1.1.2 SWD Security Level 1

SWD security level 1 allows for a customized security configuration. The physical debug port (SW-DP) is left enabled, and each function (application debug, mass erase command, factory reset command, and TI failure analysis) may be individually enabled, disabled, or (in some cases) enabled through password authentication, providing considerable flexibility to tailor the device behavior to specific use-cases.

When to Use This State

Level 1 is well suited for restricted prototyping/development scenarios and for mass production scenarios where the desire is to retain certain SWD functions (such as factory reset and TI failure analysis) while disabling other functions (such as application debug). Common examples of Level 1 customized configurations are given in Table 2-2.

Table 2-2 Examples of Level 1 Configurations
Level 1 Scenario Configuration
App Debug Mass Erase Factory Reset TI FA
This scenario restricts debug access with a user-specified password, but it leaves the factory reset and TI failure analysis available. This configuration allows field debug (with password), and it also allows the device to be brought back to the default "Level 0" state through factory reset. EN with PW DIS EN EN
This scenario does not allow debug. It does allow factory reset, but only with a user-specified password. This provides a way to open up a device in the field by clearing the MAIN memory contents and bringing the device back to a "Level 0" state if the password is known. Importantly, even if the factory reset password were compromised, it would not be possible for an attacker to read proprietary information in the MAIN flash memory. DIS DIS EN with PW EN
This scenario does not allow debug and it does not allow TI failure analysis. This prevents TI from performing a factory reset and further FA activities on the device, unless the user executes a factory reset with their user-specified password before returning the devices to TI for FA. DIS DIS EN with PW DIS
Note: Level 1 is the recommended configuration for most standard production use-cases. For applications which do not require secure boot, TI recommends using Level 1 in production with factory reset left enabled (with password) and TI failure analysis left enabled. In such a configuration, the device may be recovered to a less restrictive state after provisioning either by the user (with password) or by TI (through the failure analysis return flow). In use-cases requiring maximum secure boot assurance, a more restrictive Level 1 or Level 2 may be used for production, with the trade-off that devices may not be recoverable to a less restrictive state once provisioned.

When to Not Use this State

Level 1 should not be used during prototyping if complete access to the device is desired; in such a case, Level 0 should be used instead.

Level 1 should also not be used in a mass production scenario where a maximally restrictive state is desired and no SWD functions are to be enabled; in such a case, Level 2 should be used instead as it directly disables the complete SWD physical interface and minimizes the possibility of misconfiguration.

Note: If a device is configured with application debug and factory reset disabled, the only way for a user to restore debug access to the device is if the user application code provides a mechanism to change the NONMAIN configuration to a less restrictive state. If the NONMAIN is locked through static write protection then the state is not reversible and there is no way for a user to re-gain debug access.