• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 656 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.

Diagnosing ESM1.90

Peter Fidelman
Prodigy 200 points

Hi all,

I have a follow-up question about ESM1.90 that I did not ask in my previous thread:

I am still getting ESM 1.90's from time to time. They are not readily reproducible, but I normally get at least a few a day. I have confirmed this behavior on multiple boards, both HDK's and custom PCB's, using RM57's from SIlicon Revisions A and B.

This is indeed a benchtop environment with no (known?) radiation sources nearby to cause legitimate bit flips.  Besides, in that case I'd expect occasional bit flips in all the modules, not just SYS.

Is there any additional information available, such as an "error details" register that I can read that would specifically tell me which SYS register(s) flipped bits to trigger the ESM1.90? I understand that in the case of a SRAM, CPU, flash or interconnect fault, I could read the fault address from the EPC, but the EPC's section of spnu562 does not mention any diagnostics of the SYS module.

Basically, I'm looking for ways to confirm that the ESM1.90 indicates a real soft error in the SYS module (not an error in the diagnostics), and then identify any patterns in the fault details that might help me find the root cause.

Any suggestions?

Best,

Peter

  • 0
    TI__Guru**** 191886 points

    Hi Peter,

      As I said in the other post I have never seen this error happening on a bench environment. You are the first one to report it since we have the silicon. Other than the ESM1.90 is getting set, there is no other register to tell which one of the SYS registers is detecting the soft error. Can you reproduce the problem with a simple code or the error only happens in your full application. If you can reproduce the problem with a reduced program that does not need any input stimulus on the pins then I can try to see if I can also reproduce on my side using the HDK.