Table 4. Cpu_Sm_1 - ST STM32L4 Series User Manual

SM CODE
Ownership
Detailed implementation
Error reporting
Fault detection time
Addressed fault model
Dependency on Device configuration
Initialization
Periodicity
Test for the diagnostic
Multiple-fault protection
Recommendations and known limitations
SM CODE
Description
Ownership
Detailed implementation
Error reporting
Fault detection time
Addressed fault model
UM2305 - Rev 10
End user or ST
The software test is built around well-known techniques already addressed by IEC 61508:7,
A.3.2 (Self-test by software: walking bit one-channel). To reach the required values of
coverage, the self-test software is specified by means of a detailed analysis of all the CPU
failure modes and related failure modes distribution.
Depends on implementation
Depends on implementation
Permanent
None
None
Periodic
Self-diagnostic capabilities can be embedded in the software, according to the test
implementation design strategy chosen. The adoption of checksum protection on results
variables and defensive programming are recommended.
CPU_SM_5: External watchdog
This method is the main asset in STM32L4 and STM32L4+ Series safety concept. Hardware
integrity of the CPU is a key factor, given that the defined diagnostics for MCU peripherals are
to major part software-based.
Startup execution of this safety mechanism is recommended for multiple fault mitigations -
refer to Section 4.1.3 Notes on multiple-fault scenario
Table 4. CPU_SM_1
Control flow monitoring in Application software
End user
A significant part of the failure distribution of CPU core for permanent faults is related to
failure modes directly related to program counter loss of control or hang-up. Due to their
intrinsic nature, such failure modes are not addressed by a standard software test method like
SM_CPU_0. Therefore, it is necessary to implement a run-time control of Application software
flow in order to monitor and detect deviation from the expected behavior due to such faults.
Linking this mechanism to watchdog firing assures that severe loss of control (or, in the worst
case, a program counter hang-up) is detected.
The guidelines for the implementation of the method are the following:
• Different internal states of Application software are well documented and described (the
use of a dynamic state transition graph is encouraged).
• Monitoring of the correctness of each transition between different states of Application
software is implemented.
• Transition through all expected states during the normal Application software program
loop is checked.
• A function in charge of triggering the system watchdog is implemented in order to
constrain the triggering (preventing the issue of CPU reset by watchdog) also to the
correct execution of the above-described method for program flow monitoring. The use
of window feature available on internal window watchdog (WWDG) is recommended.
• The use of the independent watchdog (IWDG), or an external one, helps to implement a
more robust control flow mechanism fed by a different clock source.
In any case, safety metrics do not depend on the kind of watchdog in use (the adoption
of independent or external watchdog contributes to the mitigation of dependent failures, see
Section 4.2.2 Clock).
Depends on implementation
Depends on implementation. Higher value is fixed by watchdog timeout interval.
Permanent/transient
Hardware and software diagnostics
CPU_SM_0
for details.
CPU_SM_1
UM2305
page 11/110