• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 29 subscribers
  • Views 849 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570LC4357: Interconnect Self-Test Failure after LBIST / STC Success

ninja
Prodigy 250 points
Part Number: TMS570LC4357

We have the following boot flow implemented:

1) Initial power-on, run LBIST / STC, (TRM 10.9.1) which triggers reset..

2) Check LBIST / STC success status, if OK then run interconnect self-test (TRM 4.3.4), which triggers reset..

3) Check interconnect self-test status, if OK then run application.

Problem: Sometimes the interconnect self-test fails in an unexpected way. It seems to only happen when we run LBIST first as in the sequence above (e.g., we cannot see any issue if we skip LBIST) and it seems to happen more frequently (or only on) some chip samples and not others.

When the issue occurs, at step (3) we see ESMSR3.12 set ("CPU Interconnect Subsystem - Diagnostic Error") but SDC_STATUS and all SDC_ERR regs are 0.

Any suggestion on this? Is there some undocumented dependency between these two self-tests (e.g., do any of the STC registers affect the interconnect self-test in any way)?

  • 0
    Prodigy 250 points
    Digging deeper, the first sign on the problem is on the reboot after LBIST / STC. We sometimes see SDC_STATUS.GLOBAL_ERROR set along with ERR_USER_PARITY.4 (Cortex-R5F CPU master).

    So a better summary is "LBIST / STC is causing ERR_USER_PARITY.4 to be set, sometimes", we only noticed it when running the interconnect self-test afterward, but the interconnect self-test is probably not relevant at all.

    Does ERR_USER_PARITY.4 getting set during LBIST / STC point to any setup errors in the test?
  • 0 in reply to ninja
    Prodigy 250 points
    This seems to be an extension of "DEVICE#48 Interconnect Global Error flag is set after a CPU reset" errata.

    "Implication(s) The ESM group 1 channel 52 flag, Interconnect Global Error, will be set."

    It seems this can be expanded.

    "Implication(s) The ESM group 1 channel 52 flag, Interconnect Global Error, will be set AND SDC_STATUS.GLOBAL_ERROR will be set along with ERR_USER_PARITY.4."

    So the question is, given I am in this state with SDC_STATUS.GLOBAL_ERROR (this bit is unclearable according to docs) set due to a phony error, how can I successfully run the interconnect self-test? Do I need to just skip it?
  • 0 in reply to ninja
    Prodigy 250 points
    It looks like I answered my own question -- I can use SCMCNTRL.GLOBAL_ERROR_CLR to clear SDC_STATUS.GLOBAL_ERROR, which makes the interconnect self-test work. Nice!

    I do suggest to amend the errata document, change this:

    "Implication(s) The ESM group 1 channel 52 flag, Interconnect Global Error, will be set."

    to:

    "Implication(s) The ESM group 1 channel 52 flag, Interconnect Global Error, will be set AND SDC_STATUS.GLOBAL_ERROR will be set along with ERR_USER_PARITY.4."

    Then change this:

    "Workaround(s) (1)Clear the ESM group 1 channel 52 flag if set after the STC1 (CPU) self-test."

    to:

    "Workaround(s) (1)Clear the ESM group 1 channel 52 flag and the SDC global error flag (using SCMCNTRL.GLOBAL_ERROR_CLR) if set after the STC1 (CPU) self-test."



    ... otherwise, the full effects of the errata aren't documented. There is more happening than just ESM group 1 channel 52 flag getting set.
  • 0 in reply to ninja
    TI__Mastermind 49120 points
    Thank you very much for the detailed report. Yes, the interconnect global error flag in the ESM is driven by the GLOBAL_ERROR flag in the SDC. We will update the workaround description to include this requirement to also clear the GLOBAL_ERROR flag in SDC.

    Regards,
    Sunil