SDAA472 August   2026 MSPM33C321A

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
    1. 1.1 Key Concepts
  5. 2Customer Secure Code Overview
    1. 2.1 Boot and Startup Sequence
    2. 2.2 CSC Flow
    3. 2.3 FLASH Memory Map
    4. 2.4 Bank Swap
    5. 2.5 CSC Feature
      1. 2.5.1 Asymmetric Verification
        1. 2.5.1.1 SHA-256
        2. 2.5.1.2 ECDSA
        3. 2.5.1.3 MLDSA
      2. 2.5.2 Keystore
    6. 2.6 Protection on CSC
      1. 2.6.1 Write Erase Protection
      2. 2.6.2 FLASH Hide Protection
      3. 2.6.3 Data Integrity Verification
      4. 2.6.4 Secure & Privilege Protection
    7. 2.7 CSC Performance
  6. 3Evaluate CSC-based Secure Boot
    1. 3.1 Environment Setup
    2. 3.2 Program CSC
      1. 3.2.1 General
      2. 3.2.2 Step 1 - Building
      3. 3.2.3 Step 2 - Programming
    3. 3.3 Program Application
      1. 3.3.1 General
      2. 3.3.2 Step 1 - Application Image Generation – Image 1 (version 1.0.0, Located at Bank 0 – 0x10000)
      3. 3.3.3 Step 2 - Application Image Generation – Image 2 (version 2.0.0, Located at 0x20000)
      4. 3.3.4 Step 3 - Programming
    4. 3.4 Running the CSC Application
  7. 4Q&A
    1. 4.1 How to Modify the Application Image Version
      1. 4.1.1 Application Image
    2. 4.2 How to Modify the Application Image Address
      1. 4.2.1 Application Image
      2. 4.2.2 Application Image Sign Command
      3. 4.2.3 CSC Example Code
    3. 4.3 How to Modify the Slot Size
      1. 4.3.1 Application Image
      2. 4.3.2 CSC Example Code
    4. 4.4 How to Modify the Application Image Size
      1. 4.4.1 Application Image
      2. 4.4.2 Modification on Slot Size
    5. 4.5 Doing More Customization on Application Image or CSC
  8. 5References
  9. 6Revision History

2.6.3 Data Integrity Verification

The BCR supports checking the data integrity of a user-specified address range in the MAIN flash memory before transferring execution from the BCR (in ROM) to the user application (in MAIN flash memory). Please refer to MSPM33 NONMAIN Flash Memory Configuration Guide for the configuration.

The integrity check can be used as an additional step to verify that the code which runs first after the boot ROM (usually the secure boot image manager) has a CRC/SHA256 digest that matches the expected value. This integrity check reduces the likelihood that any unexpected corruption of critical code in the flash memory (which can be responsible for authenticating the remaining user application software image) can create a security vulnerability.

A start address, length, and ISO-3309 CRC-32 or SHA2-256 digest can be provisioned into the NONMAIN configuration memory. During the boot process, the BCR computes the CRC-32 digest of the specified range in the MAIN flash memory, and verify the computed digest against the provisioned (expected) digest. If the values match, the user application is started. If the values do not match, the user application is not started and the result is a catastrophic boot error.