SPRADK2A November   2024  – October 2025 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1 Introduction
  5. 2 Supplemental Online Information
  6. 3 SSU Overview
  7. 4 Key Concept Definitions
  8. 5 Safety and Security Goals
  9. 6 System Design
  10. 7 Configuring 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 Common Code Link Configuration
      4. 7.3.4 Defining Sandboxes
      5. 7.3.5 Adding Shared Memory
  11. 8 Debug Authorization
    1. 8.1 Password-Based Unlock
  12. 9 Debugging the SSU
    1. 9.1 Debugging Build Errors
    2. 9.2 Debugging Runtime Errors
  13. 10SSU Frequently Asked Questions (FAQ)
  14. 11Summary
  15. 12References
  16. 13Revision History

9.2 Debugging Runtime Errors

Various errors, from the SSU and other peripherals are captured and logged through F29x's Error Aggregator Module (EAM) and Error Signaling Module (ESM). For more information on how to view the errors coming from the EAM and ESM in CCS, please refer to the F29x Error Handling and Debug Guide application report.

Table 9-2 Possible SSU Runtime Errors
Error Example Description Resolution

C29xx_CPU1: Error during Flash Programming. Address 0x10D85000, FMSTAT (STATCMD on some devices) 0x00000000, Value 0x00000101

C29xx_CPU1: Filer Loader: Memory write failed: Unknown Error

C29xx_CPU1: GEL: File: C:\Users….. ssu_ex1_mode2.out: Load failed.

 The following error can be seen when the flash settings are not setup correctly for programming SECCFG. To allow SECCFG memory to be erased, verify the check of the “Allow NonMain Flash erase before loading data to Flash memory” checkbox within the NonMain Erase Settings section of the Flash Settings. Afterwards, re-flash your program
Note: Verify this setting is unselected when not working with SECCFG programming

CPU1_DW Errors (HP Error Addr = 0x60070018, LP Error Addr = 0x00000000, PC = 0x10010646)

SECURITY VIOLATION

 The following error indicates that the instruction located at program counter (PC) address 0x10010646 tried to write data to address 0x60070018, but was not able to due to not having sufficient permissions to do so.

To debug this issue, look up the PC address in the CCS Disassembly view (View -> Disassembly). This shows where the program counter is. This gives insights into the code execution (ie, which function and line of that function) the write access was prohibited. For this example, the program counter was located in the ‘update_PSFB()’ function located within LINK4.

Next, open the memory browser in CCS (View -> Memory) and enter in the address 0x60070018). This provides the content in memory that the instruction was going to write to. In this case, 0x60070018 corresponds to UARTA regs. The memory map in the F29x DS can also be utilized to correlate the provided error addresses with register set. In this case, user can look up 0x6007_0000 in the memory map.

Thus, LINK4 needs to be given R/W access to UARTA peripheral in order for the code within the ‘update_PSFB()’ function to write to the UARTA registers.

Note:

There are many kinds of CPU1 errors such as PR, DR1, DR2, etc. For more details on what these individual types of errors mean please refer to the Error Aggregator chapter within the TRM or the F29x Error Handling and Debug Guide application report.

SSU Errors (HP Error Addr = 0x3008000C, LP Error Addr = 0x00000000, PC = 0x00000000)

CPU1_SSU_MMR_ACCESS_ERROR

 The error showcases that the SSU was not allowed to access one of the SSU memory mapped registers (MMR). To debug this issue, start by looking up the provided address in the CCS memory browser (View -> Memory). The address 0x3008000C corresponds to LINK2_AP_OVERRIDE. The 'Search' feature within CCS was used to locate all of the instances for which ‘SSU_enableLink2APOverride()’ was called within the project. In this example, the function ‘SSU_enableLink2APOverride()’ was used outside of LINK2, causing this error. Use a similar approach when encountering other SSU MMR access errors.
During Flashing- "Warning: Target CPU may be stuck in persistent fault state" Device is in SSUMODE2 and implementing memory protections. SSU mode needs to be changed to SSU Mode 1 when the SSU is not intended to be used with safety and security protections enabled. To do this, reprogram SECCFG to put device in SSUMODE1 and reprogram to BANKMODE0 in BANKMGMT.
  • Load the default seccfg program to device found. The default seccfg program is located at this path: C:\ti\<f29h85x-sdk_version_x>\source\defseccfgbin
  • Provide a reset on the EVM or HW
  • Connect to target and verify that SSUMODE = 0x30 in the SSUGENREGS registers.
  • In the Flash Settings, program FLASH BANKMODE to BANKMODE 0 or verify that the desired BANKMODE is set.
  • Disconnect from target in CCS and issue an XRSN on EVM (controlSOM has an XRSN button) if the bankmode was changed.
  • Connect to target and verify that BANKMODE = 0x3 in the SSUGENREGS or the desired BANKMODE got set correctly.