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

FIQ as NMI and OSEK CAT1 interrupts in safety systems

Eugene K
Expert 1685 points

As I understand in TMS570 FIQ was 're-qualified' as NMI for safety reasons. All fatal or nearly fatal system error sources are connected to ESM which in turn asserts FIQ(NMI) request to CPU.

Some OSEK vendors for TMS570 use FIQ as the only CAT1 interrupt source. While it is still possible to nest non ESM FIQs through VIM there is an issue with controlling interrupts at the peripheral and possibility of phantom interrupts. It is desirable to have the trap for phantom interrupts in safety system to be able to catch subtle timing issues from design flaws. If FIQ/NMI becomes CAT1 interrupt then phantom interrupts become the 'feature' of the system.

This FIQ mapping may be even more relevant to AUTOSAR complex drivers where timing could be critical and RTOS should be bypassed with CAT1 interrupts.

Is it acceptable from from IEC61508 or ISO26262 as it applies to TMS570 to use NMIs for CAT1 interrupts for not fatal system errors and peripheral drivers?

Thanks,

Eugene

 

  • 0
    TI__Mastermind 23000 points

    Hi Eugene,

    On a TMS570 Cortex R4/R4F based CPU device, you have the capability for the CPU to process the FIQ as an NMI.  SW can check the NMFI bit to see if this function is enabled.  This capability was done for interrupt response time purposes; it was not done for any safety reasons.  However, we do rely on the function to provide a fast indication of catastrophic failure of safety diagnostics.  This is the same concept as on our TMS470 devices which do not have NMI capability but instead use FIQ - you want to signal catastrophic errors with the fastest mechanism available to the device to ensure a quick diagnostic response time.

    IEC 61508 and ISO 26262 have no direct requirements on interrupts, but there are recommendations of how interrupts could be tested in a system.  Similarly, there are no rules in IEC 61508 or ISO 26262 which uniquely apply to AUTOSAR or OSEK, but there are some general recommendations for operating systems.  Ultimately it is the responsibility of the system integrator to guarantee safe interaction of the hardware and software.  When both elements are COTS products which are designed out of context, aligning the assumptions on the system can get very tricky.

    If I were writing a hardware/software interface from scratch, to be used for development of custom hardware and software, I would recommend the use of different exception priorities for standard interrupts, high priority interrupts, and catastrophic diagnostic errors as a starting point.  The TMS470, TMS470M, and TMS570 devices have the hardware capability to support this behavior though multiple priority levels found in the VIM module.

    Regards,

    Karl