• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 29 subscribers
  • Views 545 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TMS570LC4357: Flash and RAM uncorrectable ECC errors identification

TMS570LS3137: Source of ESM Group3 ECC error

Chuck Wong
Genius 3950 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: TMS570LC4357, , HALCOGEN

I would like to ask a related question to this thread started by Gael: https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/591548?tisearch=e2e-sitesearch&keymatch=tms570%2525252525252520activate%2525252525252520static%2525252525252520ram%2525252525252520ecc 

Gael was asking the question with regards to the TMS570LC4357 with the Cortex-R5F ARM core, and Chuck Devenport has indicated in his answer (resolved) that this new core is somehow different in the handling then previous generation of Hercules MCU, in which the context might be lost because of the latency in reporting the error detection.

My apologies for my original answer which doesn't account for the architectural differences in the TMS570LC43x compared with our earlier Hercules devices. In this specific device, the RAM and Flash reside on the L2 Bus which causes some latency when they are accessed and, therefore, latency in reporting of the uncorrectable error conditions. Because of this latency, we rely on the event bus mechanism within the R5F to flag the uncorrectable error and rout this through the EPC. The draw back of this is we loose the context of the uncorrectable error regarding whether it was in Flash or RAM and the ability to latch the address for which it occurred. In short, we cannot discern if an uncorrectable error originates in SRAM or Flash.

My question is whether the "previous Hercules MCU" does include the TMS570LS3137 MCU (Cortex-R4F core), because in my case, every time when a power-up RAM ECC has occurred, tracing to the source was always changing, so impossible to know which instruction has cause the ESM Group3 RAM ECC error.

Thank you!

  • 0
    TI__Mastermind 49120 points

    Yes, TMS570LS3137 implements the Flash and RAM interfaces as tight-coupled memory interfaces. If the CPU reads from a Flash or tightly-coupled SRAM location with a double-bit ECC error, the CPU will enter a prefetch/data abort exception state and the relevant information about the error cause and address will be saved in the CPU registers to be processed in the abort handlers.

  • 0 in reply to Sunil Oak
    Genius 3950 points

    Thanks Sunil,

    That answered my question.

    However my underlying issue is still the same as the last time I contacted you privately for helps, the very same:

    No matter where the ARM core Auxiliary Control Register ACTLR bit B0TCM and/or bit B1TCM ECC checking were enabled (even or odd SRAM bank), either in C startup code (assembler code) before the main(), or after entering the main() and after Global memory HW init completed, a cold boot will hang the execution by going into the Abort() exception handler.

    If a new download with the same code is performed via the debugger while it is hung, normal execution resumes.

    Am I missing something?

  • 0 in reply to Chuck Wong
    TI__Mastermind 49120 points

    Hi Chuck,

    I remember the issue you posted the last time. The abort mode status and address registers can be used to identify the actual cause of the error. The data abort handler generated by HALCoGen identifies an abort that is intentionally generated by identifying the address that caused the error.

    Not being able to see the issue first hand and not being very familiar with your application software, I can only suggest ways to proceed with the debug starting from the contents of the abort status and address registers.