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: Reliability of safety mechanisms

Part Number: TMS570LC4357

Dear Sirs,

we were discussing internally about which mechanisms from all the set of available features we like to use in a Safety Critical application.

We ended up disabling all group 1 interrupts, just because we don't want them to disturb normal operation of the CPU due to errors that we would ignore anyhow (the code is executing, anyhow). We decided to just poll the status word and log any event.

For group 2 this is not settable though. All ESM group 2 events will trigger an event.

One of my colleagues asked "so how can we protect the system from being continuously interrupted by something that we cannot fix anyhow?" and I took the action to ask you guys.

Is there any recommendation on how to prevent race conditions that may arise from the ESM and other event handlers (like dabort, undef, etc)?

Thank you in advance.

  • Hi Txema,

    You are correct. The ESM Group2 errors always generate a high priority interrupt, and they are not programmable. When several exceptions occur simultaneously, they are serviced in a fixed order of priority: reset -- Data abort -- FIQ -- IRQ -- Prefetch -- Undef and SVC.

    Each exception is handled in turn before execution of the user program continues. The IRQs are disabled on entry to all exceptions, and the FIQs are disabled on entry to FIQ and RESET.

  • Thank you Wang.

    Are you aware of any situation where the ESM Group 2 faults produce so many FIQ interrupts that avoid normal execution of the code and where disabling these interrupts would have made the system work?

    I also have a question regarding Group 3. If they are even more critical than Group 2, why do they not produce any FIQ?

  • The ESM group 2 channels are error high severity. When any group 2 error occurs, the ESM module will then generate an interrupt request to the VIM module. Finally the VIM module will generate a FIQ interrupt request to the CPU. In esmHighInterrupt handler user will find out what leads to the ESM error and handle it per his/her application.

    The ESM group 33 (high severity) channels have no interrupt response as they are reserved for CPU based diagnostics that generate aborts directly to the CPU.