SM CODE CPU_SM_0
Ownership End user or ST
Detailed implementation
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.
Error reporting Depends on implementation
Fault detection time Depends on implementation
Addressed fault model Permanent
Dependency on Device configuration None
Initialization None
Periodicity Periodic
Test for the diagnostic
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.
Multiple-fault protection CPU_SM_5: External watchdog
Recommendations and known limitations
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 for details.
Table 4. CPU_SM_1
SM CODE CPU_SM_1
Description Control flow monitoring in Application software
Ownership End user
Detailed implementation
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).
Error reporting Depends on implementation
Fault detection time Depends on implementation. Higher value is fixed by watchdog timeout interval.
Addressed fault model Permanent/transient
UM2305
Hardware and software diagnostics
UM2305 - Rev 10
page 11/110
To Next Page
Loading...
Need help?
General
