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

TMS570LS1224: Recommend design for nERROR pin

Mallela Kumar
Prodigy 60 points
Part Number: TMS570LS1224
Other Parts Discussed in Thread: HALCOGEN

Hello TI  Team,

 

The nERROR can be monitored externally as an indicator of a fault condition in the microcontroller. An external circuit that monitors the nERROR pin must take the appropriate action to ensure that

the system is placed in a safe state.

 

Currently we are not utilizing/Not connected the nERROR pin of TMS570LS1224 Micro. Please provide some reference hardware designs for the usage of nERROR pins.

It helps us to modify our hardware design and improve the product safety.

 

Do we really need to monitor the nERROR pin?? (Because we configure ESM to Interrupts instead of nERROR pin in Halcogen ESM configuration).

Please suggest us in detail about the nERROR pin.

  • 0
    TI__Guru 59540 points

    Hello Mallela,

    Ideally, you would judge the need and implementation of the nERROR pin in your system. During our certification process, we anticipated that the nERROR pin would be monitored externally such that the external device could then put the MCU into a safe state. Below is a capture from our Safety Manual that defines the operating modes of the Hercules devices including the safe state of the MCU.

    However, how you achieve a system safe state can be evaluated and considered at the higher system level. This should be considered as part of your Technical Safety Concept and how you use the MCU within your system is dependent on your overall safety goals and concepts. For sure, when we certified the device there were some conditions that we considered that required an external reset (either warm or hard reset) in order to recover from them. For example, if there is a CPU fault, how can this be recovered other than an external interaction? Essentially, if there is a CPU fault, there is no trust to the execution of the code and the MCU operation should be considered unpredictable at the highest levels. The indication to the system at that point is the nERROR pin. The same considerations can be made for many of the elements in the RED blocks of the Safety Island Concept discussed in the Safety Manual and as indicated in the diagram below.

    Another point to consider; if you do not use the nERROR pin to indicate to the external system that the MCU is in a fault mode, how is the external system to know when to place the system into a safe state? If you are relying on a communication protocol, you are assuming that the protocol is infallible and that the code running on the MCU will never incorrectly interpret the protocol or incorrectly communicate its status over the protocol. i.e., you are relying on SW running on a system that could potentially be faulty or incorrectly operating. As a final word, the overall scheme is, as mentioned, up to your. There can be may solutions to singular problems and the solution may be different if you are not trying to achieve the same safety levels we have targeted (SIL3/ASIL D) and at the end of the day, you will have to present your solution to an assessor and justify your concept and how you protect your safety goals.