Arm Cortex -M3 Cpu; Table 5. Cpu_Sm_0; Table 6. Cpu_Sm_1 - ST STM32F2 Series User Manual

3.6.1 ®
Arm Cortex
SM CODE
Description
Ownership
Detailed implementation
Error reporting
Fault detection time
Addressed fault model
Dependency on MCU configuration
Initialization
Periodicity
Test for the diagnostic
Multiple faults protection
Recommendations and known
limitations
SM CODE
Description
Ownership
Detailed implementation
Error reporting
UM1845 - Rev 4
®
-M3 CPU
Table 5.
CPU_SM_0
Periodical core self-test software for Arm
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
Depending on implementation
Depending on implementation
Permanent
None
None
Periodic
Self-diagnostic capabilities can be embedded in the software, according 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 STM32F2 Series safety concept. CPU integrity is a key factor, given
that the major part of defined diagnostics for MCU peripherals are software-based
Table 6.
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 the 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:
• The different internal states of the application software is well documented and described (the use of
a dynamic state transition graph is encouraged).
• The monitoring of the correctness of each transition between different states of the application
software is implemented.
• The transition through all expected states during the normal application software program loop is
checked.
• The 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 the window feature 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
Depends on implementation
Description of hardware and software diagnostics
CPU_SM_0
® ®
Cortex -M3 CPU
CPU_SM_1
UM1845
Section 4.2.2 Clock)
page 13/108