• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 368 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:

Several questions regarding the eFuse controller

TMS570LS1224: Which abort handler is called in response to eFuse autoload error (ESM Group 3, Channel 1)

Marcus Coxon
Prodigy 250 points
Part Number: TMS570LS1224

I understand that all Group3 errors result in an abort but my question is how should this be handled by the code: in more detail:

  1. Specific case: eFuse autoload error, Group 3 Chan 1:
    What abort handler is called from the ".intvecs" vector table?  The TRM (SPNU515C) provides the following example of the vector table but the two highlighted abort handlers don't sound appropriate for this particular error.

  2. General case: same question for ECC related Group 3 errors.

Marcus

  • 0
    TI__Guru**** 197036 points

    Hi Marcus,

    The EFUSE autoload error (ESM 3.1) will not generate abort, but generate a error signal on the nERROR pin.

    ECC uncorrectable error will generate abort (data abort or prefetch abort).

  • 0
    Prodigy 250 points

    Hi QJ, thanks for your succinct answer that lays bare my fundamental misunderstanding (assumptions-assumptions!); the question now is "since ESM Group 3 errors do not gen interrupts, how can the code detect that an eFuse ESM Group 3, Chanel 1 event, has occurred?".

    Marcus

  • 0 in reply to Marcus Coxon
    Prodigy 250 points

    I'm now beginning to think that I'm wrong in another assumption: I was assuming that eFuse errors could be reported at any time but I'm now considering the possibility that such reports only occur after the deassertion of PORRST; if this is the case, then the s/w simply has to run the recommended eFuse self test (Fig 33-1 in the TRM) after reset, for which the first step is to check for ESM group 3, channel 1, i.e. the problem I expressed in my original reply re "how can the code detect ..." is not a problem during run-time after the reset has been handled.

    Marcus

  • 0 in reply to Marcus Coxon
    TI__Guru**** 197036 points

    The EFC Autoload Error flag will set when the autoload fails. It is the bit10 of the EFCPINS register in the EFC module.

  • 0 in reply to QJ Wang
    Prodigy 250 points

    Hi QJ, thanks for the additional info but I suspect that I wasn't sufficiently precise in expressing my question re "since ESM Group 3 errors do not gen interrupts, how can the code detect ..."; what I was trying to ask was how can the code be informed that the event had occurred during "normal running" since there is no associated interrupt or abort that can asynchronously prompt the code, rather than having to poll the reg's.

    However, none of this matters if I'm correct in my assumption, as expressed in my last posting, that the  ESM group 3, channel 1 error is only reported immediately after power-up; if this is the case, a simple "yes you are correct" reply will allow me to close this issue as Resolved.

    Marcus

  • +1 in reply to Marcus Coxon
    TI__Guru**** 197036 points

    Hi Marcus,

    Yes, you are correct. EFC self-test can be used to validate the ECC logic after the device reset is released. For safety critical application, the user needs to check the status of EFC or status of ESM group 3 after the device is reset. The suggested flow chart for checking EFC is shown in Figure 33-1 in TRM.

    The ESM 3.1 means the error is a server error. The external safety monitor needs to be configured to put the system in a safe state when nERROR is asserted.