The Safety Management Unit (SMU) is a dedicated subsystem designed to monitor, detect, and respond to system faults, ensuring the safe operation of the microcontroller-based system. The SMU plays a vital role in functional safety by continuously supervising critical system parameters, including voltage levels, clock stability, memory integrity, and peripheral functionality. It can take corrective actions such as triggering safe-state transitions, resetting the system, or alerting external safety mechanisms to prevent catastrophic failures. By integrating a SMU, designers can enhance the robustness of safety-critical applications, ensuring compliance with international safety standards.

Feature list​

The SMU implements the following features:

  • Collects every alarm signal generated from safety mechanisms

  • Alarm flags are stored in a diagnosis register that is only reset by the Power-on reset, to enable fault diagnosis and possible recovery

  • An alarm emulation function is provided to enable software-based diagnostics to post an alarm condition with the same properties as the hardware alarms

  • Implements the access protection and Safety ENDINIT modes to protect configuration registers

  • Implements a Fault Signaling Protocol (FSP) reporting internal faults to the external environment. The FSP can be configured using the following modes:

    • Bi-stable single pin output, also called ErrorPin (push-pull active low configuration using SMU_FSP0)

    • Timed dual rail coding using two inverted values on the ErrorPins (SMU_FSP0 and SMU_FSP1)

    • Single-bit timed protocol using the ErrorPin

  • The FSP value driven by the microcontroller can be observed via the FSP Status Register

    • Additionally a monitor is available to check the timing and state properties of the FSP protocol when a fault is reported

  • After power-on reset the FSP is disabled. Software needs to connect the FSP to port using the Port Control Register

  • Each individual alarm can be configured to activate the fault signaling protocol

  • Two SMU instances: one located in the core domain called SMU_core and another in the stand-by domain called SMU_stdby

  • Alarms processed in SMU_core can be configured to activate one of the following internal actions:

    • Generate an interrupt request to any of the CPUs, concurrent interrupts to several CPUs can be configured

    • Generate a NMI request to the System Control Unit

    • Generate a reset request to the System Control Unit

    • Activate the Port Emergency Stop signal controlling the safe state of output pads

    • Activate FSP output error notification

    • Generate a CPU reset request

  • All power and temperature related alarms are processed in a redundant way by both the SMU_core and SMU_stdby

  • Implements an SMU Alive alarm which signals if the SMU_core is not triggering the configured reaction when an alarm is raised

  • After reset every alarm reaction, except for watchdog time-out alarm, is disabled

  • A lock mechanism is available to protect the SMU configuration against unintended modification

  • Implements internal watchdog(s) time-out pre-warning function

  • Implements an internal watchdog called recovery timer to monitor the execution of critical software error handlers. The watchdog is started automatically by hardware according to configurable alarm events

Functional description​

The SMU is a central component of the safety architecture providing a generic interface to manage the behavior of the microcontroller under the presence of faults. The SMU centralizes all the alarm signals related to the different hardware and software-based safety mechanisms. Each alarm can be individually configured to trigger internal actions and/or notify externally the presence of faults via a fault signaling protocol. The severity of each alarm shall be configured according to the needs of the safety application(s): per default every alarm reaction is disabled with the exception of the watchdog time-out alarms. For debug and diagnosis purposes the alarm signals set a sticky bit, which is resilient to application or system resets. The SMU also implements some housekeeping functions related to the management and test of dedicated safety mechanisms. A special test mode is available to test the SMU itself enabling to detect latent faults. In addition to the register access protection, the SMU implements a configuration locking mechanism.

Figure 1. SMU block diagram


Moreover, in order to mitigate the potential common cause faults, the SMU is partitioned in two parts:

  • SMU_core: located in the core domain

  • SMU_stdby: located in the stand-by domain

The SMU_core and SMU_stdby are diverse in the way they are designed and in their timing. There is a physical separation between the two parts of the SMU. They are located in different clock and power domains. This allows the SMU to process any incoming alarm regardless of the frequency of the clock used to generate this alarm. Also, alarm events generated on fSPB (or derivatives) will be processed by the SMU_core and alarm events generated on fBACK by the SMU_stdby. This way, all Clock Alive Monitor alarms are processed in the same clock domain as they are generated. Moreover, power and temperature related alarms are processed in a diverse way since they are processed by both SMU_core and SMU_stdby. One or more reactions to these alarms could be configured in the SMU_core or the SMU_stdby.

Also, in order to detect errors in the SMU_core an alarm, smu_core_alive, is sent from the SMU_core to the SMU_stdby. The reaction to these alarms is configurable in both domains. However, for the SMU_stdby, only no reaction or setting the ErrorPins in high impedance state can be configured as an alarm reaction.