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.3 FLASH Memory Map

Figure 2-3 shows the detailed flash memory map in the CSC secure boot. The following are the explanations of sections in CSC:

  • SECRET: The SECRET is visible to the CSC but is protected by a read-protect firewall, thus rendering the SECRET invisible to the application. The SECRET region can store non-volatile keys that are loaded into KEYSTORE at runtime. Thus, the application can use these keys without having read access. Customize the SECRET to include additional information such as tag and key.
  • Lockable Flash: The lockable flash provides dynamic write protection to key information that needs to be written by the CSC and be read but unmodified by the application. The security counter (rollback protection), the keystore hash table, and the image hash are typically stored in the lockable flash. Notice that the lockable content is programmed to CSC region in PB0 only, to make sure both bank application programs can access this region.
  • CSC Interrupt Vectors: These are the interrupt vectors for the customer secure code. This interrupt vector table is the first thing run from flash in the event of a BOOTRST or a SYSRST with default VTOR. In CSC, VTOR is updated with address of the application interrupt vectors, then SYSRST with configured VROT leads the device to start from application.
    Note: SYSRST does not reset VTOR, meaning that after CSC is executed, the device does not enter CSC again until next BOOTRST.
  • CSC Code: The main code and security primitives is the bulk of the Customer Secure Code. Typically, the CSC code and the interrupt vectors only need to be programmed to Physical Bank 0 because CSC is executed before bank swap take effect. During a bank swap, after the SYSRST triggered by INITDONE, the Program always runs from the application in Logical Bank 0 (logic address). FLASHCTL maps the address to PB0 address or PB1 address according to bank swap policy configuration.

The following are sections of the application image:

  • Image Header, Image TLV and Image Trailer: generated by signing tool imgtool, which is provided by MCUBOOT (located with python scripts in <mspm33_sdk_path>\source\third_party\mcuboot\scripts). These parts are generated and merged to a compiled application image in the CCS post-build step. There is a customer_secure_sample_image example in MSPM33 SDK which shows how a signed image is built in CCS. The following are the explanations of those image parts:
    • Image Header: The header information of application image, including the header magic (0x96F3B83D), image size and image version. The image header is located at the address 0x200 bytes (by default) before the application interrupt vectors.
    • Image TLV: MCUBOOT defines Type-length-value records (TLV) containing image metadata which are placed after the end of the image. The TLVs defined in MSPM33 CSC includes: TLV magic (0x6907), image hash, ECDSA public key hash, ECDSA signature, MLDSA public key hash and MLDSA signature. For more details, see mcuboot/docs/design.md at main · mcu-tools/mcuboot · GitHub.
      Note: A SHA256 is only executed for the content including image header, application interrupt vectors and application image.
    • Image Trailer: A 16-bytes magic content which is located at the end of image flash areas.
  • Application Interrupt Vectors: These are separate interrupt vectors that the application uses. During the CSC jumping to the application, the vector table offset register (VTOR) points to this position in memory, and thus all future interrupts occur without a reset(BOOTRST or higher reset) links to this set of interrupt vectors. The start address is 32-bytes aligned.
    Note: For ARM Cortex-M33, there is a requirement on the VTOR address alignment for 0x200. Please refer to E2E thread for more information.
  • Application code: The original application code.
CSC Flash Map Figure 2-3 CSC Flash Map