• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 985 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.

TMS570LC4357: Unable to clear nError pin after WarmReset

Franck WARTEL
Intellectual 450 points

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Reopening Unable to clear nError pin after WarmReset discussion

  • 0
    TI__Guru**** 199386 points
    Hi Franck,

    We need to more test before answering those questions. Thanks
  • 0 in reply to QJ Wang
    TI__Guru**** 199386 points
    Hi Franck,

    If you happen to have an nERROR and before you clear the nERROR you get a reset, then after the reset you can not use 0x5 to clear the nERROR. The internal state machine recognizes the fact that an error event has just happened. Writing a 0x5 after an error event will reset the nERROR pin.

    If there is a system reset, the ESM state machine is also reset. It lost the fact that an error event had just happened. So if you now try to reset the nERROR pin by writing 0x5 it will not work. The only way to clear the nERROR pin is either through a power on reset or by putting the nERROR pin in diagnostic mode by writing 0xA to the ESMEKR register followed by any non 0xA values to reset the nERROR pin.

    This reset causes some of the internal ESM sticky bits to get cleared. When this happens it is Unable to recognized the nERROR event before the reset. You will then use 0xA to clear the nERROR instead of 0x5.

    Sorry for my late response.
  • 0 in reply to QJ Wang
    Intellectual 450 points

    Hi QJ,

    Thanks for your answer.

    You refer to two reset types in your answer, one "reset" for which  the ESM state machine is not loss and "system reset" which  leads to the observed behavior and diagnostic mode workaround to clear the nERROR pin.

    As far as I understood the types of reset are :

    • Power on reset upon nPORRST or VMON
    • System reset upon nRST
    • Software system reset upon update of SYSECR
    • Other internal resets following monitoring or autotests sequence/sanctions

    It is now clear to me that :

    • nPORRST  => ESM fully reseted, nERROR automatically resetted to not active state
    • nRST => ESM resetted, nERROR not automatically cleared, ESM state lost implying a diagnostic mode forcing before nERROR reset

    Can you please clarify the behavior for the remaining error sources :

    • Software system reset (SYSECR)
    • Internal resets (OSCRST, WDRST, DBGRST, ICSRST... )

    Do you intend to improve the TRM or raise an errata on this topic, so that end users can trace an official TI document to implement this diagnostic mode forcing workaround ?

    Is there any plan to take this behavior into account in HALCoGen generated code ?

    Thanks for your support,

    Regards,

     

  • 0 in reply to Franck WARTEL
    TI__Guru**** 199386 points
    Hi Franck,

    All the resets except for debug reset will reset the ESM module.

    Thanks for your good suggestion, I will check if we can add a note in the TRM. Since this is not a regular procedure to clear the nERROR pin, we don't want to change the HALCoGen.
  • 0 in reply to QJ Wang
    Intellectual 450 points

    Hi QJ,

    I am not sure to understand your answer about not correcting HALCoGen.

    The "regular" procedure described in the TRM is not valid in case a reset source different than power reset occurs, then the regular HALCoGen extract from procedure esmInit() below is not operational in all cases :

       /** - Reset error pin */
        if (esmREG->EPSR == 0U)
        {
            esmREG->EKR = 0x00000005U;
        }
        else
        {
            esmREG->EKR = 0x00000000U;
        }

    Can you please tell me then what is the regular procedure to clear the nError pin ?

    Thanks,

    Franck.

  • 0 in reply to Franck WARTEL
    TI__Guru**** 199386 points
    Hi Franck,

    The ESM first captures the error and waiting for user to clear the flag after the LtCnt times out. The flag is cleared before you have a reset. This is what I mean by "regular procedure".

    At startup, if any error flag is detected, the error may occur before the reset or after the reset. Also the reset source (SYSESR) is cleared before esmInit().

    Anyway, I will file a report to SW development team.
  • 0 in reply to QJ Wang
    Intellectual 450 points

    Hi QJ,

    Thanks for clarifying what you meant by "regular procedure".

    The ESM conditions I consider in my analysis are the ones for which there is no guarantee that the software still behaves properly and for which an external monitoring of the nError signal is needed to take appropriate sanction such as TMS system reset / power reset. In such cases the application cannot be trusted to clear the nError.

    In any case you gave me all the pieces of information I need, and that would indeed be nice to raise a ticket to at least update the TRM.

    Regards,

    Franck.