ST STM32F2 Series User manual

Introduction
This document describes how to use the microcontrollers of the STM32F2 Series in the context of a safety-related system,
specifying the user's responsibilities for installation and operation in order to reach the targeted safety integrity level.
This manual applies to the microcontrollers of the STM32F2 Series and to X-CUBE-STL part number.
System designers can avoid going into the details of the functional safety standards application of the STM32F2 Series by
following the indications reported in this manual.
This manual is written in compliance with IEC 61508. It indicates how to use the STM32F2 Series microcontrollers in the context
of other functional safety standards such as safety machine directives ISO 13849.
The safety analysis summarized in this manual takes into account the variation in terms of memory size, internal peripheral
number and package among the different part numbers of the Arm ® Cortex® -M3 based STM32F2 Series microcontrollers.
This manual has to be read along with the technical documentation for the related part numbers (such as reference manuals
and datasheets) available on www.st.com.
STM32F2 Series safety manual
UM1845
User manual
UM1845 - Rev 4 - August 2018
For further information contact your local STMicroelectronics sales office.
www.st.com

1About this document
1.1 Purpose and scope
This document describes how to use the Arm ® Cortex ® -M3 based STM32F2 Series in the context of a safety-
related system, specifying the user's responsibilities for installation and operation, in order to reach the desired
safety integrity level.
This document is useful to system designers willing evaluate the safety of their solution embedding one or more
STM32F2 Series microcontroller(s).
Note: Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
1.2 Terms and abbreviations
Abbreviations related to STM32F2 Series hardware modules (like DMA, GPIO etc.) are the same than the ones
used in STM32F2 Series technical documentation. See the following table for a list of acronyms used in this
document.
Table 1. Terms and abbreviations
Acronym Definition
CCF Common cause failure
CM Continuous mode
COTS Commercial off-the-shelf
CoU Conditions of use
CPU Central processing unit
CRC Cyclic redundancy check
DC Diagnostic coverage
DMA Direct memory access
DTI Diagnostic test interval
ECM Engine control module
ECU Electronic control unit
EUC Equipment under control
FIT Failure in time
FMEA Failure mode effect analysis
FMEDA Failure mode effect diagnostic analysis
HD High demand
HFT Hardware fault tolerance
HW Hardware
ITRS International technology roadmap for semiconductors
LD Low demand
MCU Microcontroller unit
MTBF Mean time between failure
UM1845
About this document
UM1845 - Rev 4 page 2/108

Acronym Definition
MTTFd Mean time to failure
NA Not available
PDS(SR) Power drive system (safety related)
PEc Programmable electronics - core
PEd Programmable electronics - diagnostic
PFD Probability of Dangerous Failure on Demand
PFH Probability of failure per hour
PL Performance level
PST Process safety time
SFF Safe failure fraction
SIL Safety integrity level
SRCF Safety-related control function
SRECS Safety-related electrical control systems
SRP/CS Safety-related parts of control systems
SW Software
Read also the following definitions used within this manual:
• End user: the STM32F2 Series final user of that is in charge of integrating the MCU in a real application (for
example an electronic control board).
• Application software: the actual software running on the STM32F2 Series MCUs and implementing the
safety function.
1.3 Reference normative
This document is written in compliance with the IEC 61508 international norm for functional safety of electrical,
electronic and programmable electronic safety-related systems.
The version used as reference is IEC 61508:1-7 © IEC:2010.
The other functional safety standards considered in this manual are the following:
• ISO 26262-1, 2, 3, 4, 5, 6, 7, 8, 9: 2011(E), ISO 26262-10: 2012(E),
• ISO 13849-1:2006, ISO 13849-2:2010,
• IEC 62061:2012-11, ed. 1.1,
• IEC 61800-5-2:2007, ed.1.0,
The following table reports the mapping of this document content with respect to the requirements listed in the
IEC 61508-2 Annex D.
Table 2. Mapping between this document content and IEC 61508-2 Annex D requirements
IEC 61508 requirement (part 2 annex D) Reference
D2.1 a) a functional specification of the functions capable of being performed Section 3
D2.1 b) identification of the hardware and/or software configuration of the compliant item Section 3.2
D2.1 c) constraints on the use of the compliant item or assumptions on which analysis of the behavior or
failure rates of the item are based Section 3.2
UM1845
Reference normative
UM1845 - Rev 4 page 3/108

IEC 61508 requirement (part 2 annex D) Reference
D2.2 a) the failure modes of the compliant item due to random hardware failures, that result in a failure of
the function and that are not detected by diagnostics internal to the compliant item;
Conditions of use
D2.2 b) for every failure mode in a), an estimated failure rate;
D2.2 c) the failure modes of the compliant item due to random hardware failures, that result in a failure of
the function and that are detected by diagnostics internal to the compliant item;
D2.2 d) the failure modes of the diagnostics, internal to the compliant item due to random hardware
failures, that result in a failure of the diagnostics to detect failures of the function;
D2.2 e) for every failure mode in c) and d), the estimated failure rate;
D2.2 f) for every failure mode in c) that is detected by diagnostics internal to the compliant item, the
diagnostic test interval; Section 3.2.2
D2.2 g) for every failure mode in c) the outputs of the compliant item initiated by the internal diagnostics; Section 3.6
D2.2 h) any periodic proof test and/or maintenance requirements;
Conditions of use
D2.2 i) for those failure modes, in respect of a specified function, that are capable of being detected by
external diagnostics, sufficient information must be provided to facilitate the development of an external
diagnostics capability.
D2.2 j) the hardware fault tolerance;
Section 3
D2.2 k) the classification as type A or type B of that part of the compliant item that provides the function
(see 7.4.4.1.2 and 7.4.4.1.3);
The safe failure fraction reported in this manual has been computed under the assumptions described in this
document and especially according to the conditions of use described in Conditions of use.
UM1845
Reference normative
UM1845 - Rev 4 page 4/108

2STM32F2 Series microcontroller development process
The development process of a microelectronic device that is used in safety critical application takes into account
the adequate management to reduce the probability of systematic faults introduced during the design phase.
IEC 61508:2 in Annex F (Techniques and measures for ASICs - avoidance of systematic failures) act as a
guidance in tailoring the microcontroller standard design and manufacturer process to the compliance of the IEC
61508 requirements. The checklist reported in the named Annex F helps to collect all related evidences of a given
real process.
2.1 STMicroelectronics standard development process
STMicroelectronics (ST) serves four industry domains:
• Standard products.
• Automotive products: ST automotive products are AEC-Q100 compliant. They are subject to specific stress
testing and processing instructions in order to achieve the required quality levels and product stability.
• Automotive safety: a subset of the automotive domain. ST uses as a reference the ISO 26262 Road vehicles
Functional safety standard. ST supports customer inquiries regarding product failure rates and FMEDA to
support hardware system compliance to established safety goals. ST provides products that are safe in their
intended use, working in cooperation with customers to understand the mission profile, adopt common
methods and define countermeasures for residual risks.
• Medical products: ST complies with applicable regulations for medical products and applies due diligence in
the development and validation of these products.
STMicroelectronics product development process, compliant with the ISO/TS 16949 standard, is a set of
interrelated activities dedicated to transform customer specification and market or industry domain requirements
into a semiconductor device and all its associated elements (package, module, sub-system, application,
hardware, software and documentation), qualified respecting ST internal procedures and able to be manufactured
using ST internal or subcontracted technologies.
Figure 1. presents a summary of the STMicroelectronics product-development process.
UM1845
STM32F2 Series microcontroller development process
UM1845 - Rev 4 page 5/108

Figure 1. STMicroelectronics product development process
· Key characteristics and
requirements related to future
uses of the device
· Industry domain(s), specific
customer requirements and
definition of controls and tests
needed for compliance
· Product target specification
and strategy
· Project manager
appointment to drive product
development
· Evaluation of the
technologies, design tools
and IPs to be used
· Design objective
specification and product
validation strategy
· Design for quality techniques
(DFD, DFT, DFR, DFM, …)
definition
· Architecture and positioning
to make sure the software
and hardware system
solutions meet the target
specification
· Product approval strategy
and project plan
· Semiconductor design
development
· Hardware and application
development
· Software development
· Analysis of new product
specification to forecast
reliability performance
· Reliability plan, reliability
design rules, prediction of
failure rates for operating life
test using Arrhenius’s law and
other applicable models
· Use of tools and
methodologies such as
APQP, DFM, DFT, DFMEA,
FMKM
· Detection of potential
reliability issues and solution
to overcome them
· Assessment of Engineering
Samples (ES) to identify the
main potential failure
mechanisms
· Statistical analysis of
electrical parameter drifts for
early warning in case of fast
parametric degradation (such
as retention tests)
· Failure analysis on failed
parts to clarify failure modes
and mechanisms and identify
the root causes
· Physical destructive analysis
on good parts after reliability
tests when required
· Electrostatic discharge (ESD)
and latch-up sensitivity
measurement
· Successful completion of
the product qualification
plan
· Secure product deliveries
on advanced technologies
using stress methodologies
to detect potential weak
parts
· Successful completion of
electrical characterization
· Global evaluation of new
product performance to
guarantee reliability of
customer manufacturing
process and final application
of use (mission profile)
· Final disposition for product
test, control and monitoring
1 Conception 3 Qualification
2 Design &
validation
UM1845
STMicroelectronics standard development process
UM1845 - Rev 4 page 6/108

3Reference safety architecture
This section reports the details of the STM32F2 Series safety architecture.
3.1 Safety architecture introduction
The STM32F2 Series microcontroller analyzed in this document can be used as a compliant item within different
safety applications.
The aim of this section is to identify such compliant item and therefore to define the context of the analysis in
terms of assumptions with respect to a reference concept definition. This concept definition includes therefore
reference safety requirements as also assumptions on the design external to the defined compliant item.
As a consequence of compliant item approach, the goal is not to provide an exhaustive hazard and risk analysis
of the system around the microcontroller, but rather to list the system-related information considered during the
analysis. Such information include - among others - application related assumptions for dangerousness factors,
frequency of failures and diagnostic coverage already guaranteed by the application.
3.2 Compliant item
This section includes all the information related to the definition of the compliant item, including its usage in
different safety architecture schemes.
3.2.1 Definition of the compliant item
According to IEC 61508:1 clause 8.2.12, a compliant item is any item (for example an element) on which a claim
is being made with respect to the clauses of IEC 61508 series. With respect to its user, at the end of its
development the compliant item must be described by a safety manual.
In this document, the compliant item is defined as a system including one or two STM32 microcontrollers (MCU)
(see Figure 2.). The communication bus is directly or indirectly connected to sensors and actuators.
Figure 2. Definition of the compliant item
Remote
controller
Remote
controller
Remote
controller
Remote
controller
Sensor
Actuator
S
S
A
A
Processing element
Compliant item
STM
MCU(s)
Other components might be related to the compliant item, like the external HW components needed to guarantee
either the functionality of the STM32F2 Series (external memory, clock quartz etc) or its safety (for example the
external watchdog, voltage supervisors).
Defined compliant item can be classified as “element” according IEC61508-4, 3.4.5.
3.2.2 Safety functions performed by the compliant item
In essence, the compliant item architecture can be represented as composed by the following processes
performing the safety function or part of it:
• Input processing elements (PEi) reading safety related data from the remote controller connected to the
sensor(s) and transferring them to the following computation elements;
UM1845
Reference safety architecture
UM1845 - Rev 4 page 7/108

• Computation processing elements (PEc) performing the algorithm required by the safety function and
transferring the results to the following output elements;
• Output processing elements (PEo) transferring safety related data to the remote controller connected to the
actuator;
• In the case of the 1oo2 architecture, a further voting processing element (PEv) can be present;
• Processes external to the compliant item are considered to guarantee safety integrity, such as a watchdog
(WDTe) and voltage monitors (VMONe).
The role of the PEv and of the external processes WDTe and VMONe is clarified in the sections where the CoU
(definition of safety mechanism) are detailed:
• WDTe: refer to Independent watchdog – VSUP_SM_2, Control flow monitoring in application software –
CPU_SM_1,
• VMONe: refer to Supply Voltage Monitoring – VSUP_SM_1.
In summary, STM32F2 Series microcontrollers support the implementation of end user safety functions composed
by three operations:
• Safe acquisition of safety related data from input peripheral(s).
• Safe execution of application software program and safe computation of related data.
• Safe transfer of results or decisions to output peripheral(s).
Claims on the compliant item and computation of safety metrics are done with respect to these three basic
operations.
According to above reported definition for implemented safety functions, the compliant item i.e. the element can
be regarded as type B (as per IEC61508-2, 7.4.4.1.2 definition). Despite accurate, exhaustive and detailed failure
analysis has been done for STM32F2 Series, this device has to be considered intrinsically complex and therefore
type B classification is appropriate.
Two main safety architecture are therefore identified: 1oo1 (using one MCU) and 1oo2 (using two MCUs).
3.2.3 Reference safety architectures - 1oo1
In 1oo1 reference architecture (shown in below Figure 3.) the safety integrity of the compliant item is guaranteed
by the combination of STM32F2 Series internal processes (implemented safety mechanisms) and external
processes WDTe and VMONe.
Target for 1oo1 reference architecture is SIL2.
Figure 3. 1oo1 reference architecture
PEc Actuators
WDTe
Sensors
VMONe
PEoPEi
PEd
UM1845
Compliant item
UM1845 - Rev 4 page 8/108

3.2.4 Reference safety architectures - 1oo2
1oo2 reference architecture (shown in below Figure 4.) is composed by two separate channels, each of them
implemented in the same way of 1oo1 reference architecture. Safety integrity of each channel is guaranteed by
the combination of STM32F2 Series internal processes (implemented safety mechanisms) and external
processes WDTe and VMONe. Safety integrity of overall compliant item is guaranteed by the external voter PEv
allowing to claim HFT=1. Achievement of higher safety integrity levels as per IEC61508-2 Table 3 is therefore
possible. Appropriate separation between the two channels (including power supply separation) should be
implemented in order to avoid huge impact of common-cause failures (refer to Section 4.2 Dependent failures
analysis). βD computation is anyway required.
Target for 1oo2 reference architecture is SIL3.
Figure 4. 1oo2 reference architecture
Actuators
Sensors
VMONe
PEc PEoPEi
PEd
WDTeVMONe
PEv
PEc PEoPEi
PEd
WDTe
UM1845
Compliant item
UM1845 - Rev 4 page 9/108

3.3 Assumed requirements
This section collects all assumptions done during the safety analysis of STM32F2 Series microcontrollers
3.3.1 Assumed safety requirements
The concept specification, the hazard and risk analysis, the overall safety requirement specification and the
consequent allocation has determined the requirements for the compliant item (ASR: assumed safety
requirements) listed here below.
Caution: It is the end user’s responsibility to check the compliance of the final application with these assumptions.
ASR1: The compliant item can be used for four kinds of safety functions mode of operations according part 4,
3.5.16:
• A continuous mode or high-demand SIL3 safety function (CM3), or
• A low-demand SIL3 safety function (LD3), or
• A continuous mode or high-demand SIL2 safety function (CM2), or
• A low-demand SIL2 safety function (LD2).
ASR2: The compliant item is used to implement a safety function allowing a time budget of 10 ms (worst case) for
the STM32 MCU to detect and react to a failure. That time corresponds to the portion of the Process Safety Time
allocated to STM32F2 Series MCUs (“STM32xx Series duty” in the figure below) in error reaction chain at system
level.
Figure 5. Allocation and target for STM32 PST
System-level PST
MCU detection FW reaction SW reaction Actuator reaction
STM32xx Series duty End user duty ….
ASR3: The compliant item is used in a safety function that can be continuously powered-on for a time higher than
8 hours. It is assumed to not require any proof test and the lifetime of the product is considered to be not less than
10 years.
ASR4: It is assumed that only one safety function is performed or if many, all functions are classified with the
same SIL and therefore they are not distinguishable in terms of their safety requirements.
ASR5: In case of multiple safety functions implementations, it is assumed that end user is responsible to
guarantee their needed mutual independence.
ASR6: It is assumed that there are no “non-safety related” functions implemented in application software and
coexisting with the safety functions.
ASR7: It is assumed that the implemented safety function(s) is not depending on STM32F2 Series MCU transition
to and from a low-power state.
ASR8: The local safe state of the compliant item is the one in which either:
• SS1: the application software is informed by the presence of a fault and a reaction by the application
software itself is possible
• SS2: the application software cannot be informed by the presence of a fault or the application software is not
able to execute a reaction (1)
1. The end user must take into account that random hardware failures affecting the STM32 can compromise the MCU
capability of operating properly (for example failure modes affecting the program counter prevent the correct execution of
software).
UM1845
Assumed requirements
UM1845 - Rev 4 page 10/108

Details on safe states SS1 and SS2 are provided in the following table:
Table 3. SS1 and SS2 safe state details
Safe
state Condition Compliant item action
System Transition to Safe
state – 1oo1 architecture
System Transition to Safe
state – 1oo2 architecture
SS1
The application software is
informed by the presence of a
fault and a reaction by the
application software itself is
possible.
Fault reporting to
application
software
Application software drives
the overall system in his safe
state
Application software in one of
the two channels drives the
overall system in his safe
state
SS2
The application software cannot
be informed by the presence of a
fault or the application software is
not able to execute a reaction.
Reset signal
issued by WDTe
WDTe drives the overall
system in his safe state
(“safe shut-down”) (1)
PEv drives the overall system
in his safe state
1. Safe state achievement intended here is compliant to Note on IEC61508-2, 7.4.8.1
ASR9: It is assumed that the safe state defined at system level by the end user is compatible with the assumed
local safe state (SS1, SS2) for the compliant item.
ASR10: The compliant item is assumed to be analyzed according to routes 1H and 1S of IEC 61508-2.
Note: refer to Section 3.5 Systematic safety integrity and Section 3.6 Description of hardware and software
diagnostics.
ASR11: The compliant item is assumed to be regarded as type B as per IEC61508:2, 7.4.4.1.2.
3.4 Electrical specifications and environment limits
The user must not exceed the electrical specification and the environmental limits defined in the below list as
reported in the STM32F2 Series user manual in order to guarantee the STM32F2 Series safety integrity:
• Absolute maximum rating,
• Capacity,
• Operating conditions.
Due to the large number of STM32F2 Series part numbers, the related user manuals and datasheets are not
listed in this document; users are responsible to carefully check the above reported limits in the technical
documentation on the related part number available on .
3.5 Systematic safety integrity
According to the requirements of IEC 61508 -2, 7.4.2.2, the Route 1S has been considered in the STM32F2
Series development. As clearly authorized by IEC61508-2, 7.4.6.1, STM32 MCU series can be considered a
standard, mass-produced electronic integrated device – for which stringent development procedures, rigorous
testing and extensive experience of use minimizes the likelihood of design faults. Anyway, an internal assessment
against the compliance of STM32 MCU development flow with the techniques and measures suggested in IEC
61508-2 Annex F has been executed. The Safety Case Database (Section 5 List of evidences) maintains the
evidences of the compliance to the norm.
3.6 Description of hardware and software diagnostics
This section lists all the safety mechanisms (hardware, software and application level) considered in the safety
analysis of the microcontrollers of the STM32F2 Series. It is expected that users are familiar with the STM32F2
Series architecture, and that this document is used in conjunction with the related device datasheet, user manual
and reference information. Therefore, to avoid the eventuality of mistakes and reduce the amount of information
to be shown, minimum functional details are included in this document. In following descriptions the words “safety
mechanism”, “method” or “requirement” are used as synonym.
UM1845
Electrical specifications and environment limits
UM1845 - Rev 4 page 11/108

Note that each part number of the STM32F2 Series owns different combinations of peripherals (for instance,
some of them are not equipped with USB peripheral). To reduce the number of documents and avoid information-
less repetitions, the current Safety Manual (and therefore this section) addresses the overall possible peripherals
available in the targeted part numbers. Users have to select which peripherals are really available on their
devices, and discard the meaningless recommendations accordingly.
The implementation guidelines reported in the following section are for reference only. The safety verification
executed by ST during STM32F2 Series safety analysis and related diagnostic coverage figures reported in this
manual (or its Annexes) are based on such guidelines. For the sake of clarity, safety mechanism are grouped for
MCU basic functions.
Information are organized in form of tables (one for each safety mechanism). Table 4. below presents the
explanation of each field:
Table 4. Safety mechanism field explanation
SM CODE
Unique safety mechanism code/identifier used also in FMEA document. Identifiers use the scheme mmm_SM_x
where mmm is a 3 or 4 letter module acronym, and “x” is an incremental number. Please note that module
acronym and numbering could be not sequential and/or different from module's actual name being derived by
legacy documents.
Description Short mnemonic description
Ownership
ST : means that method is available on silicon
End user: method must be implemented by the end user by application software modification, hardware
solutions, or both.
Detailed implementation Detailed implementation sometimes including notes about the safety concept behind the introduction of the
safety mechanism.
Error reporting Describes how the fault detection is reported to application software
Fault detection time Time that the safety mechanism needs to detect the hardware failure
Addressed fault model
Reports fault model(s) addressed by the diagnostic (Permanent, Transient, or both), and other information:
If ranked for Fault avoidance: method contributes to lower the probability of occurrence of a failure
If ranked for Systematic: method is conceived to mitigate systematic errors (bugs) in application software design
Dependency on MCU
configuration
Reports if safety mechanism implementation or characteristics change among different part numbers belonging
to STM32F2 Series
Initialization Specific operation to be executed to activate the contribution of the safety mechanism
Periodicity
Continuous : safety mechanism is active in continuous mode
Periodic: safety mechanism is executed periodically. Note that safety mechanism can be accounted for
diagnostic coverage contribution only if it is executed at least one per PST
On Demand: safety mechanism is activated in correspondence of a specified event (for instance, reception of a
data message)
Startup: safety mechanism is supposed to be executed only at power-up or during off-line maintenance periods
Test for the diagnostic Reports specific procedure (if any and recommended) to allow on-line tests of safety mechanism efficiency
Multiple faults protection Reports the safety mechanism(s) associated in order to correctly manage a multi-fault scenario (refer to Section
4.1.3 Notes on multiple faults scenario)
Recommendations and
known limitations Additional recommendations or limitations (if any) not reported in other fields
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 12/108

3.6.1 Arm® Cortex®-M3 CPU
Table 5. CPU_SM_0
SM CODE CPU_SM_0
Description Periodical core self-test software for Arm® Cortex®-M3 CPU
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 Depending on implementation
Fault detection time Depending on implementation
Addressed fault model Permanent
Dependency on MCU configuration None
Initialization None
Periodicity Periodic
Test for the diagnostic
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
Multiple faults protection CPU_SM_5 : external watchdog
Recommendations and known
limitations
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
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 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 Section 4.2.2 Clock)
Error reporting Depends on implementation
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 13/108

SM CODE CPU_SM_1
Fault detection time Depends on implementation. Higher value is fixed by watchdog timeout interval.
Addressed fault model Permanent and Transient
Dependency on MCU
configuration None
Initialization Depends on implementation
Periodicity Continuous
Test for the diagnostic NA
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known
limitations -
Table 7. CPU_SM_2
SM CODE CPU_SM_2
Description Double computation in application software
Ownership End user
Detailed implementation
A timing redundancy for safety-related computation is considered to detect transient faults affecting the
Arm® Cortex®-M3 CPU subparts devoted to mathematical computations and data access.
The guidelines for the implementation of the method are the following:
• The requirement needs be applied only to safety-relevant computation, which in case of wrong
result could interfere with the system safety functions. Such computation must be therefore carefully
identified in the original application software source code
• Both mathematical operation and comparison are intended as computation.
• The redundant computation for mathematical computation is implemented by using copies of the
original data for second computation, and by using an equivalent formula if possible
Error reporting Depends on implementation
Fault detection time Depends on implementation
Addressed fault model Transient
Dependency on MCU
configuration None
Initialization Depends on implementation
Periodicity Continuous
Test for the diagnostic Not needed
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known
limitations
End user is responsible to carefully avoid that the intervention of optimization features of the used
compiler removes timing redundancies introduced according to this condition of use
Table 8. CPU_SM_3
SM CODE CPU_SM_3
Description Arm® Cortex®-M3 HardFault exceptions
Ownership ST
Detailed implementation
HardFault exception raise is an intrinsic safety mechanism implemented in Arm® Cortex®-M3 core,
mainly devoted to intercept systematic faults due to software limitations or error in software design
(causing for example execution of undefined operations, unaligned address access). This safety
mechanism is also able to detect hardware random faults inside the CPU bringing to such described
abnormal operations
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 14/108

SM CODE CPU_SM_3
Error reporting High-priority interrupt event
Fault detection time Depending on implementation, refer to functional documentation
Addressed fault model Permanent and Transient
Dependency on MCU configuration None
Initialization None
Periodicity Continuous
Test for the diagnostic
It is possible to write a test procedure to verify the generation of the HardFault exception; anyway,
given the expected minor contribution in terms of hardware random-failure detection, such
implementation is not recommended.
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known
limitations None
Table 9. CPU_SM_4
SM CODE CPU_SM_4
Description Stack hardening for application software
Ownership End user
Detailed implementation
The stack hardening method is required to address faults (mainly transient) affecting CPU register bank.
This method is based on source code modification, introducing information redundancy in register-passed
information to called functions.
The guidelines for the implementation of the method are the following:
• To pass also a redundant copy of the passed parameters values (possibly inverted) and to execute a
coherence check in the function.
• To pass also a redundant copy of the passed pointers and to execute a coherence check in the
function.
• For parameters that are not protected by redundancy, to implement defensive programming
techniques (plausibility check of passed values). For example enumerated fields are to be checked
for consistency.
Error reporting Depends on implementation
Fault detection time Depends on implementation
Addressed fault model Permanent and Transient
Dependency on MCU
configuration None
Initialization Depends on implementation
Periodicity On demand
Test for the diagnostic Not needed
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known
limitations
This method partially overlaps with defensive programming techniques required by IEC61508 for software
development. Therefore in presence of application software qualified for safety integrity greater or equal to
SC2, optimizations are possible
Table 10. CPU_SM_5
SM CODE CPU_SM_5
Description External watchdog
Ownership End user
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 15/108

SM CODE CPU_SM_5
Detailed implementation
Using an external watchdog linked to control flow monitoring method (refer to CPU_SM_1) addresses
failure mode of program counter or control structures of CPU.
External watchdog can be designed to be able to generate the combination of signals needed on the
final system to achieve the safe state. It is recommended to carefully check the assumed requirements
about system safe state reported in Section 3.3.1 .
It also contributes to reduce potential common cause failures, because the external watchdog is clocked
and supplied independently from the STM32F2 Series
Error reporting Depends on implementation
Fault detection time Depends on implementation (watchdog timeout interval)
Addressed fault model Permanent and Transient
Dependency on MCU configuration None
Initialization Depends on implementation
Periodicity Continuous
Test for the diagnostic To be defined at system level (outside the scope of compliant item analysis)
Multiple faults protection CPU_SM_1: control flow monitoring in application software
Recommendations and known
limitations
In case of usage of windowed watchdog, end user must consider possible tolerance in application
software execution, to avoid false error reports (affecting system availability).
Table 11. CPU_SM_6
SM CODE CPU_SM_6
Description Independent watchdog
Ownership ST
Detailed implementation Using the IDWG watchdog linked to control flow monitoring method (refer to CPU_SM_1) addresses
failure mode of program counter or control structures of CPU.
Error reporting Reset signal generation
Fault detection time Depends on implementation (watchdog timeout interval)
Addressed fault model Permanent
Dependency on MCU configuration None
Initialization IWDG activation. It is recommended to use the “Hardware watchdog” in Option byte settings (IWDG is
automatically enabled after reset)
Periodicity Continuous
Test for the diagnostic WDG_SM_1: Software test for watchdog at startup
Multiple faults protection CPU_SM_1: control flow monitoring in application software
WDG_SM_0: periodical read-back of configuration registers
Recommendations and known
limitations
The IWDG intervention is able to achieve a potentially “incomplete” local safe state because it can only
guarantee that CPU is reset. No guarantee that application software can be still executed to generate
combinations of output signals that might be needed by the external system to achieve the final safe
state. If this limitation turn out in a blocking point, end user must adopt CPU_SM_5
Table 12. CPU_SM_7
SM CODE CPU_SM_7
Description MPU - Memory protection Unit
Ownership ST
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 16/108

SM CODE CPU_SM_7
Detailed implementation The CPU Memory Protection Unit is able to detect illegal access to protected memory areas, according
to End user programmed criteria
Error reporting Exception raise (MemManage)
Fault detection time Refer to functional documentation
Addressed fault model Systematic (software errors)
Permanent and Transient (only program counter and memory access failures)
Dependency on MCU configuration None
Initialization MPU registers shall be programmed at start-up
Periodicity On line
Test for the diagnostic Not needed
Multiple faults protection MPU_SM_0: Periodical read-back of configuration registers
Recommendations and known
limitations
The use of memory partitioning and protection by MPU functions is highly recommended when multiple
safety functions are implemented in application software. The MPU can be indeed used to
• enforce privilege rules
• separate processes
• enforce access rules
Hardware random-failure detection capability for MPU is restricted to well-selected failure modes,
mainly affecting program counter and memory access CPU functions. The associated diagnostic
coverage is therefore expected to be not relevant in the framework of STM32F2 Series safety concept
Table 13. MPU_SM_0
SM CODE MPU_SM_0
Description Periodical read-back of MPU configuration registers
Ownership End user
Detailed implementation
This method must be applied to MPU configuration registers (also unused by the end user
application software).
Detailed information on the implementation of this method can be found in Section 3.6.5
Error reporting Refer to NVIC_SM_0
Fault detection time Refer to NVIC_SM_0
Addressed fault model Refer to NVIC_SM_0
Dependency on MCU configuration Refer to NVIC_SM_0
Initialization Refer to NVIC_SM_0
Periodicity Refer to NVIC_SM_0
Test for the diagnostic Refer to NVIC_SM_0
Multiple faults protection Refer to NVIC_SM_0
Recommendations and known limitations Refer to NVIC_SM_0
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 17/108

3.6.2 Embedded FLASH memory
Table 14. FLASH_SM_0
SM CODE FLASH_SM_0
Description Periodical software test for Flash memory
Ownership End user or ST
Detailed implementation
Permanent faults affecting the system Flash memory, memory cells and address decoder, are addressed
through a dedicated software test that checks the memory cell contents versus the expected value, using
signature-based techniques. According to IEC 61508:2 Table A.5, the effective diagnostic coverage of such
techniques depends on the width of the signature in relation to the block length of the information to be
protected - therefore the signature computation method is to be carefully selected. Note that the simple
signature method (IEC 61508:7 - A.4.2 Modified checksum) is inadequate as it only achieves a low value of
coverage.
The information block does not need to be addressed with this test as it is not used during normal operation
(no data nor program fetch)
Error reporting Depends on implementation
Fault detection time Depends on implementation
Addressed fault model Permanent
Dependency on MCU
configuration Flash size changes according part number
Initialization Memory signatures must be stored in Flash as well
Periodicity Periodic
Test for the diagnostic Self-diagnostic capabilities can be embedded in the software, according the test implementation design
strategy chosen
Multiple faults protection CPU_SM_1: control flow monitoring in application software
CPU_SM_0: periodical core self-test software
Recommendations and known
limitations
This test is expected to have a relevant time duration – test integration must therefore consider the impact on
application software execution.
The use of internal CRC module is recommended. In principle DMA feature for data transfer can be used.
Unused Flash sections can be excluded from testing
Table 15. FLASH_SM_1
SM CODE FLASH_SM_1
Description Control flow monitoring in application software
Ownership End user
Detailed implementation
Permanent and transient faults affecting the system Flash memory, memory cells and address
decoder, can interfere with the access operation by the CPU, leading to wrong data or instruction
fetches.
Such failures can be detected by control flow monitoring techniques implemented in the application
software loaded from Flash memory.
For more details on the implementation, refer to description CPU_SM_1
Error reporting Depends on implementation
Fault detection time Depends on implementation. Higher value is fixed by watchdog timeout interval.
Addressed fault model Permanent and Transient
Dependency on MCU configuration None
Initialization Depends on implementation
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 18/108

SM CODE FLASH_SM_1
Periodicity Continuous
Test for the diagnostic NA
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known limitations CPU_SM_1 correct implementation supersede this requirement
Table 16. FLASH_SM_2
SM CODE FLASH_SM_2
Description Arm® Cortex®-M3 HardFault exceptions
Ownership ST
Detailed implementation
Hardware random faults (both permanent and transient) affecting system Flash (memory cells,
address decoder) can lead to wrong instruction codes fetches, and eventually to the intervention of
the Arm® Cortex®-M3 HardFault exceptions. Refer to CPU_SM_3 for detailed description
Error reporting Refer to CPU_SM_3
Fault detection time Refer to CPU_SM_3
Addressed fault model Permanent and Transient
Dependency on MCU configuration None
Initialization Refer to CPU_SM_3
Periodicity Continuous
Test for the diagnostic Refer to CPU_SM_3
Multiple faults protection Refer to CPU_SM_3
Recommendations and known limitations None
Table 17. FLASH_SM_3
SM CODE FLASH_SM_3
Description Option byte write protection
Ownership ST
Detailed implementation This safety mechanism prevents unintended writes on the option byte. The use of this method is
encouraged to enhance end application robustness for systematic faults
Error reporting Write protection exception
Fault detection time Not applicable
Addressed fault model None (Systematic only)
Dependency on MCU configuration None
Initialization Not needed (enabled by default)
Periodicity Continuous
Test for the diagnostic Not needed
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known limitations
This method addresses systematic faults in software application and it have zero efficiency in
addressing hardware random faults affecting the option byte value during running time. No DC
value is therefore associated
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 19/108

Table 18. FLASH_SM_4
SM CODE FLASH_SM_4
Description Static data encapsulation
Ownership End user
Detailed implementation
If static data are stored in Flash memory, encapsulation by a checksum field with encoding
capability (like CRC) must be implemented.
Checksum validity is checked by application software before static data consuming
Error reporting Depends on implementation
Fault detection time Depends on implementation
Addressed fault model Permanent and Transient
Dependency on MCU configuration None
Initialization Depends on implementation
Periodicity On demand
Test for the diagnostic Not needed
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known limitations None
Table 19. FLASH_SM_5
SM CODE FLASH_SM_5
Description Option byte redundancy with load verification
Ownership ST
Detailed implementation During option byte loading after each power-on reset, the bit-wise complementarity of the option
byte and its corresponding complemented option byte is verified. Mismatches are reported as error
Error reporting Option byte error (OPTERR) generation
Fault detection time Not applicable
Addressed fault model Permanent
Dependency on MCU configuration None
Initialization None (always enabled)
Periodicity Startup
Test for the diagnostic Not needed
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known limitations None
Table 20. FLASH_SM_6
SM CODE FLASH_SM_6
Description Flash unused area filling code
Ownership End user
Detailed implementation
Used Flash area must be filled with deterministic data. This way in case that the program counter
jumps outside the application program area due to a transient fault affecting CPU, the system
evolves in a deterministic way
Error reporting NA
Fault detection time NA
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4 page 20/108