SPRADK2 November   2024 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Supplemental Online Information
  6. 3SSU Overview
  7. 4Key Concept Definitions
  8. 5Safety and Security Goals
  9. 6System Design
  10. 7Configuring the SSU
    1. 7.1 Flash SECCFG Region
    2. 7.2 SSU Development Life Cycle
    3. 7.3 Using the SysConfig Tool
      1. 7.3.1 Enabling System Security Configuration
      2. 7.3.2 Configuring Application Modules
      3. 7.3.3 Configuring Special Modules
        1. 7.3.3.1 LINK2 Configuration
        2. 7.3.3.2 LINK1 Configuration
        3. 7.3.3.3 Adding Shared Memory
      4. 7.3.4 Defining Sandboxes
  11. 8Summary
  12. 9References

7.2 SSU Development Life Cycle

The SSU can be configured to operate in one of three modes: SSUMODE1, SSUMODE2, and SSUMODE3. These operating modes are intended to facilitate the development process as the user implements safety and security features into a system design. The SSU can be reconfigured to change from any operating mode to any other operating mode, as long as the user has the necessary permissions to update the SECCFG sector.

Units shipped from Texas Instruments start out in SSUMODE1. In this mode, the entire memory map range is mapped to LINK2 (the security root LINK), and all LINKs have full read and write access to all AP-configurable memory regions. Hard-coded protections remain active even in SSUMODE1; however, since all code runs as LINK2, there are effectively no restrictions on user code.

In SSUMODE2, AP region protections are enforced, but debug and Flash update protections remain disabled. For best results, fully validate application functionality in SSUMODE1 first, then implement SSU settings and test them in SSUMODE2. Once validation of run-time safety and security settings is completed, debug passwords can be configured, and the device can be placed in SSUMODE3. In this mode, debug ports are closed by default, authentication is enforced, and Flash update protections are active.

Note: Flash write and Flash erase protections are permanent and cannot be reversed, irrespective of the SSUMODE setting. This feature is intended for use cases where the user needs to make a certain portion of Flash code immutable, for example, for the purpose of implementing a security algorithm. Do not attempt to configure Flash write and Flash erase protections before finalizing device Flash contents.