SDAA104 September   2025 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Error Handling Architecture Overview
  6. 3Example Overview
  7. 4Error Aggregator Overview
    1. 4.1 Error Aggregation
    2. 4.2 Error Logging
    3. 4.3 Error Debugging Using EAM Module
      1. 4.3.1 EAM Error Debugging
      2. 4.3.2 Interpreting Error Address and Program Counter Values
  8. 5Error Signaling Module Overview
    1. 5.1 ESM Error Event Output Configuration and Status Information
      1. 5.1.1 Sysconfig ESM Configuration
    2. 5.2 ESM Error Events Debugging
    3. 5.3 Miscellaneous Debug Tips for ESM
  9. 6BootROM EAM and ESM Error Status
  10. 7FAQ's:
  11. 8Summary
  12. 9References

7 FAQ's:

  1. Does the user setup and configure NMI ISR ?

    Answer – Yes, this is recommended that users' setup NMI ISR during device initialization so that when high priority error occurs (for example Group0 error events) which trigger NMI to respective CPU can then gracefully clear the Error flags in EAM and ESM as per guidance in F29x TRM and ESM multicore F29 SDK example. Failure to clear ESM raw status flag causes NMIWD timeout to trigger XRSn (Device reset). User can check NMIWD bit in RESC (Reset Cause) register to confirm the same.

  2. What if there was no NMI ISR setup by application and error event caused NMI based on default settings from Group 0 ESM error events ?

    Answer - If there was no user/application NMI ISR setup then CPU goes to default NMI handler in BootROM where CPU clears and saves the error status and flags in M0 RAM address for debug. Refer to BootROM TRM chapter for more information.

  3. What happens if NMI ISR is configured but the error flags are not cleared ?

    Answer – The ESM NMIWD timeout occurs and causes High priority watchdog interrupt output from respective CPU. ESM CPU1 High priority watchdog interrupt output is connected to cause XRSn while ESM CPU2/CPU3 causes respective CPURSn as shown in ESM Subsystem Integration View diagram.

  4. What if ESM is not configured to generate NMI to respective CPU for high priority CPU EAM errors (passed to ESM as Group 0 error event) ?

    Answer – When ESM Group0 error event is active passed on through EAM module and is not configured to generate NMI, CPU goes in fault state. CPU EAM module high priority errors when active should be configured to always trigger NMI to respective CPU.

  5. Does ESM/EAM flags clear after XRSn (Device Reset) or CPURSn (CPU Reset) ?

    Answer – No, error type register (which is referred to as EAM error flags in this document) and ESM RAW status register (RAW_j) (which is referred to as ESM error flags) are only reset by PORESETn. These flags retain the value even after XRSn and CPURSn since application needs this error flag information for debug in case of reset triggered by ESM as response to error event occurrence not handled by application software.

  6. Why does CPU keeps entering NMI ISR even after clearing ESM Raw status register for all events that caused NMI ?

    Answer – After clearing the ESM RAW status register (RAW_j) flags make sure the EOI Register is also written to with appropriate key for corresponding error ESM interrupt output. This step of writing EOI is basically user acknowledging the ESM interrupt output which de-asserts the ESM output. If EOI register is not written to then ESM interrupt output remains asserted even if ESM error event flag is cleared.

  7. Is it possible to generate NMI to CPU1 only and not to CPU3 and vice-versa based on a specific error event occurence ?

    Answer – Yes, ESM is highly configurable and since there are separate ESM tiles dedicated for each CPU it is possible to setup configuration during initialization to generate NMI or any other error response to either CPU from its respective ESM CPU tile and disable error response or configure different error response for particular error event from another ESM CPU tile.