STMicroelectronics STM32H7 Series Microcontroller User manual

UM2840

User manual

STM32H7 dual-core safety manual

Introduction

This document must be read along with the technical documentation such as reference manual(s) and datasheets for the

STM32H7 dual-core microcontrollers, available on www.st.com

.

It describes how to use the devices 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. It also pertains to the X-CUBE-STL software product.

It provides the essential information pertaining to the applicable functional safety standards, which allows system designers to avoid going into unnecessary details.

The document is written in compliance with IEC 61508.

The safety analysis in this manual takes into account the device variation in terms of memory size, available peripherals, and package.

This manual addresses the STM32H7 dual-core microcontrollers (named as STM32H7 dual core), that include two CPU cores, the Arm ® Cortex ® -M7 and Cortex ® -M4.

UM2840 - Rev 1 - July 2021

For further information contact your local STMicroelectronics sales office.

www.st.com

1

1.1

Note:

UM2840

About this document

About this document

Purpose and scope

This document describes how to use Arm ® Cortex ® -M7-based STM32H7 dual-core

microcontroller unit (MCU) devices (further also referred to as Device

(s)) 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.

It is useful to system designers willing to evaluate the safety of their solution embedding one or more Device(s) .

For terms used, refer to the glossary at the end of the document.

Note that this manual addresses the STM32H7 dual-core microcontrollers, that are devices with two CPU cores, the Arm ® Cortex ® -M7 and Cortex ® -M4.

Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

1.2

Normative references

This document is written in compliance with the IEC 61508 international norm for functional safety of electrical, electronic and programmable electronic safety-related systems, version IEC 61508:1-7 © IEC:2010. The

compliance to other functional safety standards is considered in reference document [3]

.

The following table maps the document content with respect to the IEC 61508-2 Annex D requirements.

Safety requirement

D2.1 a)

D2.1 b)

D2.1 c)

D2.2 a)

D2.2 b)

D2.2 c)

D2.2 d)

D2.2 e)

Table 1. Document sections versus IEC 61508-2 Annex D safety requirements

3

3.2

3.2

Section number

General information are provided in Section 4.1

.

Detailed information on failure modes and related failure rates are included in other reference documents

[1]

,

[2]

referred in

Section 1.3 .

D2.2 f)

D2.2 g)

D2.2 h)

D2.2 i)

D2.2 j)

D2.2 k)

Useful information for DTI of each safety mechanisms are provided in related specification tables (filed

“Periodicity”) of

Section 3.6 . General guidance on DTI is included in

Section 3.3.1

Because of the software-based nature of Device safety concept, the outputs of the Compliant Item triggered by internal diagnostics are decided at application software level, and so they cannot be described in this manual.

Periodic proof test is excluded by specific ASR3.1 in Section 3.3.1

3.7

3.2.3

,

3.2.4

3.2.2

UM2840 - Rev 1 page 2/132

1.3

UM2840

Reference documents

Reference documents

[1]

[2]

[3]

AN5631, Results of FMEA on STM32H7 dual-core microcontrollers

AN5596, Results of FMEDA on STM32H7 dual-core microcontrollers

AN5689, Adapting the X-CUBE-STL functional safety package for STM32 (IEC 61508 compliant) to other safety standards

UM2840 - Rev 1 page 3/132

2

UM2840

Device development process

Device development process

STM32 series product development process (see

Figure 1

), compliant with the IATF 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, hardware, software, and documentation), qualified with ST internal procedures and fitting ST internal or subcontracted manufacturing technologies.

Figure 1. STMicroelectronics product development process

1 Conception

2 Design and validation

3 Qualification

· 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 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

· 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

UM2840 - Rev 1 page 4/132

3

3.1

3.2

3.2.1

UM2840

Reference safety architecture

Reference safety architecture

This section reports details of the STM32H7 dual-core safety architecture.

Note that this manual addresses the STM32H7 dual-core microcontrollers, that include two CPU cores, the Arm

Cortex-M7 and Cortex-M4.

Safety architecture introduction

Device (s) analyzed in this document can be used as Compliant item (s) within different safety applications.

The aim of this section is to identify such Compliant item (s), that is, to define the context of the analysis with respect to a reference concept definition. The concept definition contains reference safety requirements, including design aspects external to the defined Compliant item .

As a consequence of Compliant item approach, the goal is to list the system-related information considered during the analysis, rather than to provide an exhaustive hazard and risk analysis of the system around the device. Such information includes, among others, application-related assumptions for danger factors, frequency of failures and diagnostic coverage already guaranteed by the application.

Compliant item

This section defines the Compliant item term and provides information on its usage in different safety architecture schemes.

Definition of Compliant item

According to IEC 61508-1 clause 8.2.12, 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. Any mature Compliant item must be described in a safety manual available to

End user .

In this document, Compliant item

is defined as a system including one or two STM32 devices (see Figure 2 ). The

communication bus is directly or indirectly connected to sensors and actuators.

Figure 2. STM32 as Compliant item

Actuator

Sensor

S

S

Remote controller

Remote controller

Processing element

STM32 device(s)

Compliant item

Remote controller

Remote controller

A

A

Other components might be related to the Compliant item , like the external HW components needed to guarantee either the functionality of the device (external memory, clock quartz and so on) or its safety (for example, the external watchdog or voltage supervisors).

A defined Compliant item can be classified as element according to IEC 61508-4, 3.4.5.

UM2840 - Rev 1 page 5/132

UM2840

Compliant item

3.2.2

Caution:

•

•

•

•

Safety functions performed by Compliant item

In essence, Compliant item architecture encompasses the following processes performing the safety function or a 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 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 1oo2 architecture, potentially a further voting processing element (PEv) in charge to facilitate the safety function processing by each of the two channels, individually.

the computation processing elements can be involved (to the extent depending to the target safety integrity) in the implementation of local software-based diagnostic functions; this is represented by the block PEd processes external to Compliant item ensuring safety integrity, such as watchdog (WDTe) and voltage monitors (VMONe)

The role of the PEv process is clarified in Section 3.2.4 Reference safety architectures - 1oo2

. The role of the

WDTe and VMONe external processes is clarified under Section 3.6 Hardware and software diagnostics

:

• WDTe: refer to External watchdog

CPUM7_SM_1, CPUM4_SM_1,

– CPU_SM_5 and Control flow monitoring in Application software –

• VMONe: refer to Supply voltage monitoring – VSUP_SM_1 and System-level power supply management -

VSUP_SM_5.

•

•

In summary, Devices support the implementation of End user safety functions consisting of 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 Compliant item and computation of safety metrics are done with respect to these three basic operations.

Because of general purpose nature of Device, its safety concept is mainly software-based. Accordingly, any following claim related to the possibility of Device itself to support the implementation of safety functions up to a

certain SIL is strongly correlated to the observance of CoUs as requested in Section 3.7 .

Because STM32H7 MCU includes two separate CPUs (Arm

®

Cortex

®

-M7 and Cortex

®

-M4), the safety function(s) and so the related three above decribed sub-operations can be performed by different possible schemes. Two main schemes are possible:

•

•

Individual scheme: each CPU may implement a specific safety function, with no collaboration from other

CPU

Collaborative scheme: the two CPUs collaborate for the implementation of the same safety function(s)

The two schemes are shown in the following figure, where the notation SF1(s), SF2(s), SF(s) means that each

"channel" can be used to implement one or multiple safety functions.

UM2840 - Rev 1 page 6/132

UM2840 - Rev 1

UM2840

Compliant item

PEi

Figure 3. Individual and collaborative schemes

PEi1 PEc1

CPU1

PEo1

PEi12

PEi2

PEc2

CPU2

Individual scheme

PEo2

PEc1

CPU1

PEc2

CPU2

Collaborative scheme

PEo

SF1(s)

SF2(s)

SF(s)

The schemes can be embedded in the reference safety architectures described below.

Consequences related to the coexistence on the two CPUs in the same MCU are embedded in related Assumed

Safety Requirements (refer to

Section 3.3 Safety analysis assumptions ) and Conditon of Use (refer to

Section 3.7 Conditions of use ); related rationales are exposed in

Section 3.2.5 The separation concept .

According to the definition for implemented safety functions, Compliant item (element) can be regarded as type B

(as per IEC 61508-2, 7.4.4.1.3 definition). Despite accurate, exhaustive and detailed failure analysis, Device has to be considered as intrinsically complex. This implies its type B classification.

Two main safety architectures are identified: 1oo1 (using one Device ) and 1oo2 (using two Devices ).

page 7/132

UM2840

Compliant item

3.2.3

3.2.3.1

Reference safety architectures - 1oo1

1oo1 reference architecture ( Figure 4 ) ensures safety integrity of

Compliant item through combining Device internal processes (implemented safety mechanisms) with external processes WDTe and VMONe. In this architecture Device is considered intrinsically having hardware fault tolerance (HFT) equal to 0.

1oo1 reference architecture targets

safety integrity level (SIL)

SIL2 . Both individual and collaborative scheme are possible.

Individual scheme

Figure 4. 1oo1 reference architecture - individual scheme

VMONe WDTe

Sensors

PEi1

PEi12

PEi2

PEc1

CPU1

PEd1

PEc2

CPU2

PEd2

SF1

PEo1

SF2

PEo2

Actuators

1

Actuators

2

Caution:

3.2.3.2

In the framework of individual scheme, the two chains PEi1/PEc1/PEo1 and PEi2/PEc2/PEo2 implement separate sets of safety function(s). Individual set of external actuators are involved in the safety function(s) implementation.

Link between WDTe and actuators show the capability of the external watchdog to force the safe state.

All implemented safety function(s) share a common management for safe state and PST requirement - refer to

Section 3.3 Safety analysis assumptions for related ASR.

Collaborative scheme

Figure 5. 1oo1 reference architecture - collaborative scheme

VMONe WDTe

Sensors PEi

PEc1

CPU1

PEd1

PEc2

CPU2

PEd2

PEo Actuators

In the collaborative scheme, both CPUs are involved in the implementation of the same safety function(s). The

CPUs connection order is just informative and it is not constrained.

UM2840 - Rev 1 page 8/132

3.2.4

UM2840

Compliant item

Reference safety architectures - 1oo2

1oo2 reference architecture ( Figure 6 ) contains two separate channels, both implemented as 1oo1 reference

architecture ensuring safety integrity of Compliant item through combining Device internal processes

(implemented safety mechanisms) with external processes WDTe and VMONe. The overall safety integrity is then ensured by the external voter PEv, which allows claiming

hardware fault tolerance (HFT)

equal to 1. The

PEv role is indeed to facilitate the safety function processing by each of the two individual channels, to allow the safety function implementation even in case one channel is faulty. The PEv complexity implementation is strongly dependent on the nature of the safety function and safe state definitions. Achievement of higher safety integrity levels as per IEC 61508-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 Analysis of dependent failures

). However, β and βD parameters computation is required.

1oo2 reference architecture targets SIL3 , under the assumption that each channel follows all requirements indicated for SIL2 in this manual. Pay attention: according the clause 7.4.3.2 in IEC 61508-2, this architectural scheme may provide benefits to the software applications systematic capability (SC) only in case diverse software is adopted in the two channels. For the sake of simplicity, only collaborative scheme is adopted for 1oo2 architecture.

Figure 6. 1oo2 reference architecture

VMONe WDTe

PEi

PEc1

CPU1

PEd1

PEc2

CPU2

PEd2

PEo

Sensors

PEv Actuators

PEi

PEc1

CPU1

PEd1

PEc2

CPU2

PEd2

PEo

VMONe WDTe

UM2840 - Rev 1 page 9/132

3.2.5

UM2840

Compliant item

The separation concept

The coexistence of two different CPU (Arm

®

Cortex

®

-M7 and M4) on the Device is managed by the means of the STM32H7 dedicated separation concept, shown in this section. The separation concept mitigates potential interferences between the two CPUs (and their software) and it is composed by two different aspects, spatial separation and temporal separation.

Spatial separation

Arm ® Cortex ® -M7 and M4 coexist on the same device and so they share the control and the access to common resources, like SRAM, Flash, peripherals. Interferences are therefore possible, but in the lack of hardware-built segregation features for the CPUs, they are mitigated by a combination of requirements driving the implementation of final application:

• CoU_10 and CoU_11 forces the implementation of a kind of “private” SRAMs, one for each CPU, which is quite valuable when individual scheme is adopted. Possible interferences are mitigated by the static allocation of the SRAM and by dynamic checking performed by the two MPUs, as requested by CoU_12

• Because of CoU_15, each CPU has its “private” watchdog which can be triggered just by the CPU itself – this mitigates any potential issues related to the management of the required external watchdog.

Furthermore, CoU_16 guarantee that the software routines charged of watchdog management and safety data exchange between CPUs are always active because developed with highest systematic capability.

Temporal separation

The two CPUs Arm ® Cortex ® -M7 and M4 can boot in independent way and this makes them not strictly linked from temporal point of view. Anyway, the effectiveness of the spatial separation (see above) is correlated to the actual capability of prescribed hardware and software to correctly functioning. Accordingly, it is End user responsibility to guarantee by system-level measures and solutions the safe state during the STM32H7 boot. The

CPU separation cannot be considered working until at least CoU_17 (startup tests) is satisfied.

UM2840 - Rev 1 page 10/132

UM2840

Safety analysis assumptions

3.3

3.3.1

Caution:

Note:

Note:

Safety analysis assumptions

This section collects all assumptions made during the safety analysis of the devices.

Safety requirement assumptions

The safety concept specification, the overall safety requirement specification and the consequent allocation determine the requirements for Compliant item as further listed. ASR stands for assumed safety requirement.

•

•

•

It is End user ’s responsibility to check the compliance of the final application with these assumptions.

ASR1: Compliant item can be used to implement four kinds of safety function modes of operation according to

IEC 61508-4,3.5.16: a a a

continuous mode (CM) low-demand (LD)

CM or HD SIL2

SIL

or high-demand (HD)

3 safety function (

safety function ( CM2

LD3

), or

SIL3

), or

safety function ( CM3 ), or

• a LD SIL2 safety function ( LD2 ).

ASR2: Compliant item is used to implement safety function(s) allowing a specific worst-case time budget (see note below) for the STM32 MCU to detect and react to a failure. That time corresponds to the portion of the

process safety time (PST)

allocated to Device ( STM32xx Series duty

in Figure 7 ) in error reaction chain at system

level.

In case of multiple safety functions implementation leading to multiple different time constraints, the shortest one must be adopted for each safety function.

As collateral effect, time constraint for the execution of periodical tests are always the same for both CPUs of the

Device.

The computation for time budget mainly depends on the execution speed for periodic tests implemented by software. Such duration might depends on the actual amount of hardware resources (RAM memory,

Flash memory, peripherals) actually declared as safety-related. Further constraints and requirements from

IEC 61508-2, 7.4.5.3 must be considered.

Figure 7. Allocation and target for STM32 PST

STM32xx Series duty

MCU detection FW reaction SW reaction

End user duty

….

Actuator reaction

System-level PST

ASR3.1: Compliant item is used to implement safety function(s) that can be continuously powered on for a period over eight hours. It is assumed to not require any proof test, and the lifetime of the product is considered to be no less than 10 years.

ASR3.2: It is assumed that the Device operates within specified electrical specifications and environment limits.

The End user is responsible for the compliance to this assumption.

ASR 4.1: It is assumed that both CPUs available in the Device (Arm safety related.

® Cortex ® -M7 and M4) are considered as

ASR4.2: It is assumed that in case multiple safety functions are implemented in the Compliant item, all functions are classified with the same SIL for hardware safety integrity and the same SC for software systematic capability and therefore they are not distinguishable in terms of their safety requirements.

ASR4.3: In case of multiple safety function implementations, it is assumed that End user is responsible to duly ensure their mutual independence.

ASR4.4: It is assumed that there are no non-safety-related functions implemented in Application software , coexisting with safety functions.

UM2840 - Rev 1 page 11/132

Note:

Note:

Note:

Note:

UM2840

Safety analysis assumptions

ASR5: It is assumed that the implemented safety function(s) does (do) not depend on transition of Device (or one of its CPUs) to and from a low-power state.

ASR6.1: The local safe state of Compliant item is the one in which either:

• SS1: Application software

(1)

is informed by the presence of a fault and a reaction by Application software itself is possible.

• SS2: Application software

(1)

cannot be informed by the presence of a fault or Application software is not able to execute a reaction.

End user must take into account that random hardware failures affecting Device can compromise its operation

(for example failure modes affecting the program counter prevent the correct execution of software).

The following table provides details on the SS1 and SS2 safe states.

Table 2. SS1 and SS2 safe state details

Safe state

SS1

SS2

Condition

Application software

is informed by the presence of a fault and a reaction by

Application software itself is possible.

(1)

Compliant

item action

Fault reporting to Application software

System transition to safe state -

1oo1 architecture

(individual scheme)

Application software

(1)

drives all implemented safety functions in their safe state, possibly leveraging on inter-

CPU communications

(CPU_SM_11)

Application software (1)

cannot be informed by the presence of a fault or Application software is not able to execute a reaction.

Reset signal issued by

WDTe

WDTe drives all implemented safety functions in their safe state (“safe shutdown”)

(2)

System transition to safe state –

1oo1 architecture

(collaborative scheme)

Application software

drives the overall

(1)

system in its safe state

WDTe drives the overall system in its safe state

(“safe shutdown”) (2)

System transition to safe state – 1oo2 architecture

Application software in one of the two channels drives the overall system in its safe state

(1)

PEv drives the overall system in its safe state

1. Any of the application software running on the two different CPUs available on Device, Arm Cortex M7 and M4 (or even both of them).

2. The safe state achievement intended here is compliant to Note on IEC 61508-2, 7.4.8.1

ASR6.2: It is assumed that the safe state(s) defined at system level by End user is compatible with the assumed local safe state (SS1, SS2) for Compliant item .

ASR6.3

: When individual scheme is adopted, it is assumed that the safe state defined at system level is compatible with the causal connection between the individual safe state of each safety functions described in

Table 2

.

According to the requirements listed on

Table 2

, the detection of a fault must cause the transition to safe state for each implemented safety functions. Accordingly, even if in priciple different safe states can be defined for the different implemented safety functions, their time evolution cannot be kept separated.

ASR7: Compliant item is assumed to be analyzed according to routes 1H and 1S of IEC 61508-2.

Refer to

Section 3.5 Systematic safety integrity

and Section 3.6 Hardware and software diagnostics .

ASR8: Compliant item is assumed to be regarded as type B, as per IEC 61508-2, 7.4.4.1.3.

ASR9.1: It is assumed that STM32H7 is not used to build fail-operational solutions based exclusively on the presence of two different CPUs in the device itself.

ASR9.2: It is assumed that a single STM32H7 instance is not used to build a HFT>0 solutions based exclusively on the presence of two different CPUs in the device itself.

ASR9.3:

It is assumed that the architecture 1oo1 with individual scheme (see Section 3.2.3 Reference safety architectures - 1oo1

) is not used to artificially implement a 1oo2 scheme with one single STM32H7 device

This assumption is placed to avoid the implementation of the same safety function of the two separate CPUs in the individual scheme, managed then with an external voter. That solution cannot be considered a true 1oo2 architecture as described in IEC 61508-6 because of the incomplete separation between the two channels.

UM2840 - Rev 1 page 12/132

3.4

Note:

3.5

UM2840

Electrical specifications and environment limits

ASR10 : When adopting individual scheme, is End user responsibility to prove the freedom from interferences between physical pins associated to different safety functions (e.g. by running a pin-level FMEDA).

ASR11 : It is assumed that is End user responsibility to correct manage the CPUs boot process (by the handling of

BOOT options) in order of implementing a boot process compliant to all requirements included in this manual.

Electrical specifications and environment limits

To ensure safety integrity, the user must operate Device (s) within its (their) specified:

• absolute maximum rating

• capacity

• operating conditions

For electrical specifications and environmental limits of Device (s), refer to its (their) technical documentation such as datasheet(s) and reference manual(s) available on www.st.com

.

The device operation within specified limits is a prerequisite for the correct implementation of any safety function. This is explicitly assumed within the assumptions (refer to above ASR3.2).

Systematic safety integrity

According to the requirements of IEC 61508-2, 7.4.2.2, the Route 1S is considered in the analysis of Device (s).

As clearly authorized by IEC 61508-2, 7.4.6.1, STM32 MCU products can be considered as standard, massproduced electronic integrated devices, for which stringent development procedures, rigorous testing and extensive experience of use minimize the likelihood of design faults. However, ST internally assesses the compliance of the Device development flow, through techniques and measures suggested in the IEC 61508-2

Annex F. A safety case database

(see Section 5 List of evidences

) keeps evidences of the current compliance level to the norm.

UM2840 - Rev 1 page 13/132

3.6

UM2840

Hardware and software diagnostics

Hardware and software diagnostics

This section lists all the safety mechanisms (hardware, software and application-level) considered in the

Device safety analysis. It is expected that users are familiar with the architecture of Device , and that this document is used in conjunction with the related Device datasheet, user manual and reference information. To avoid inconsistency and redundancy, this document does not report device functional details. In the following descriptions, the words safety mechanism , method , and requirement are used as synonyms.

As the document provides information relative to the superset of peripherals available on the devices it covers

(not all devices have all peripherals), users are supposed to disregard any recommendations not applicable to their Device part number of interest.

Information provided for a function or peripheral applies to all instances of such function or peripheral on Device .

Refer to its reference manual or/and datasheet for related information.

The implementation guidelines reported in the following section are for reference only. The safety verification executed by ST during the Device safety analysis and related diagnostic coverage figures reported in this manual

(or related documents) are based on such guidelines. For clarity, safety mechanisms are grouped by Device function.

Information is organized in form of tables, one per safety mechanism, with the following fields:

SM CODE

Description

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

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 (function, peripheral) short name, and x is a number. It is possible that the numbering is not sequential (although usually incremental) and/or that the module short name is different from that used in other documents.

Short mnemonic description

ST: means that method is available on silicon.

End user : method must be implemented by End user through Application software modification, hardware solutions, or both.

Detailed implementation sometimes including notes about the safety concept behind the introduction of the safety mechanism.

Describes how the fault detection is reported to Application software .

Time that the safety mechanism needs to detect the hardware failure.

•

•

Reports fault model(s) addressed by the diagnostic (permanent, transient, or both), and other information:

If ranked for failure

Fault avoidance : method contributes to lower the probability of occurrence of a

If ranked for Systematic : method is conceived to mitigate systematic errors (bugs) in

Application software design

Reports if safety mechanism implementation or characteristics change among different Device part numbers.

Specific operation to be executed to activate the contribution of the safety mechanism

Continuous : safety mechanism is active in continuous mode.

Periodic: safety mechanism is executed periodically

(1) .

On-demand: safety mechanism is activated in correspondence to 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.

Reports specific procedure (if any and recommended) to allow on-line tests of safety mechanism efficiency.

Reports the safety mechanism(s) associated in order to correctly manage a multiple-fault scenario

(refer to

Section 4.1.3 Notes on multiple-fault scenario

).

Additional recommendations or limitations (if any) not reported in other fields.

1. In CM systems, safety mechanism can be accounted for diagnostic coverage contribution only if it is executed at least once per PST. For LD and HD systems, constraints from IEC 61508-2, 7.4.5.3 must be applied.

UM2840 - Rev 1 page 14/132

UM2840

Hardware and software diagnostics

3.6.1

Arm ® Cortex ® -M7 CPU

SM CODE

Description

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

Table 3. CPUM7_SM_0

CPUM7_SM_0

Periodical core self-test software for Arm ® Cortex ® -M7 CPU

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 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 STM32H7 dual-core safety concept. CPU integrity is a key factor because 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.

UM2840 - Rev 1 page 15/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 4. CPUM7_SM_1

CPUM7_SM_1

Control flow monitoring in Application software

End user

A significant part of the failure distribution of Arm ® Cortex ® -M7 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:

Different internal states of the 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 the

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 and transient

None

Depends on implementation

Continuous

NA

-

CPUM7_SM_0: periodical core self-test software

UM2840 - Rev 1 page 16/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 5. CPUM7_SM_2

CPUM7_SM_2

Double computation in Application software

End user

A timing redundancy for safety-related computation is considered to detect transient faults affecting the Arm ® Cortex ® -M7 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

Depends on implementation

Depends on implementation

Transient

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_0: periodical core self-test software

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.

SM CODE

Description

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

Table 6. CPUM7_SM_3

CPUM7_SM_3

Arm ® Cortex ® -M7 HardFault exceptions

ST

HardFault exception raise is an intrinsic safety mechanism implemented in Arm ® Cortex ® -M7 core, mainly dedicated 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.

High-priority interrupt event

Depends on implementation. Refer to functional documentation.

Permanent and transient

None

None

Continuous

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.

CPUM7_SM_0: periodical core self-test software

Enabling related interrupt generation on the detection of errors is highly recommended.

UM2840 - Rev 1 page 17/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 7. CPUM7_SM_4

Stack hardening for Application software

CPUM7_SM_4

End user

The stack hardening method is required to address faults (mainly transient) affecting

Arm ® Cortex ® -M7 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.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0: periodical core self-test software

This method partially overlaps with defensive programming techniques required by IEC 61508 for software development. Therefore in presence of Application software qualified for safety integrity greater or equal to SC2, optimizations are possible.

UM2840 - Rev 1 page 18/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 8. CPUM7_SM_7

CPUM7_SM_7

Memory protection unit ( MPU )

ST

The Arm ® Cortex ® -M7 CPU memory protection unit is able to detect illegal access to protected memory areas, according to criteria set by End user .

Exception raise (MemManage)

Refer to functional documentation

Systematic (software errors)

Permanent and transient (only program counter and memory access failures)

None

MPU registers must be programmed at start-up

On line

Not needed

MPUM7_SM_0: Periodical read-back of configuration registers

•

•

•

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 not expected to be relevant for the safety concept of Device .

Enabling related interrupt generation on the detection of errors is highly recommended.

UM2840 - Rev 1 page 19/132

Description

Ownership

SM CODE

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

UM2840

Hardware and software diagnostics

Table 9. CPUM7_SM_9

CPUM7_SM_9

Periodical self-test software for Arm ® Cortex ® -M7 caches

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). The scope of the software test are failure modes affecting Arm ® Cortex ® -M7 L1 caches controllers.

The achieved diagnostic coverage strongly depends on the complexity of the test implementation, and on the percentage of caches failure modes addressed.

Depends on implementation

Depends on implementation

Permanent

None

Depends on implementation

Periodic

N/A

CPU_SM_5 : external watchdog

•

•

End user waiver of cache features, disabling it by software, leads to following benefits in STM32H7 dual-core safety concept:

No need to implement this method (CPUM7_SM_9)

Decrease of Arm ® Cortex ® -M7 overall failure rate

UM2840 - Rev 1 page 20/132

UM2840

Hardware and software diagnostics

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 10. CPUM7_SM_10

CPUM7_SM_10

ECC on Arm ® Cortex ® -M7 - L1 caches

ST

•

•

ECC on Arm ® Cortex ® -M7 - L1 cache memories (data and instructions) are protected by an ECC

(Error Correction Code) redundancy, implementing a protection feature at double-word (64 bit) level:

One bit fault: correction

Two bits fault: detection

Errors correction/detection are reported on IEBR0-1, DEBR0-1 registers. Refer to Arm ® documentation for further details.

ECC bits are checked during cache usage

Permanent/Transient

None

None

Continuous

Direct test procedure for ECC efficiency is not available. ECC run-time hardware failures leading to the disable of such protection, or to wrong corrections, fall into a “multiple fault scenario” from IEC 61508 perspective. Related failures are adequately mitigated by the combination of safety mechanisms reported in this table, field "Multiple-fault protection". Read also the note on

"Recommendations and known limitations" field.

CPUM7_SM_1 control flow monitoring in application software

CPUM7_SM_3: Arm ® Cortex ® -M7 HardFault exceptions

CPUM7_SM_4 stack hardening for application software

RAM_SM_3 information redundancy for safety-related variables in application software

Important note: because of the lack of ECC direct test procedure, single-fault failures leading to unintended ECC correction may cause an incorrect data read from Flash memory. This is why STM32H7 dual-core safety concept strongly recommends the adoption of multiple layers of overlapped safety mechanisms which collaborate to mitigate such kind of ECC failures. Refer to

[1] for further detailed information on ECC failures mitigation strategy.

Important : there is no interrupt notification for caches ECC correction/detection. Accordingly,

IEBR0-1 and DEBR0-1 registers must be periodically monitored to collect errors notifications.

The polling operation for these registers must be executed at least once per PST (see also note

1 in Section 3.6 Hardware and software diagnostics ). It is strongly recommended to do not

use "Valid" bit function in IEBR0-1, DEBR0-1 to implement fault-tolerant schemes on the CPU caches, because of limited capability of such invalidate function.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Table 11. MPUM7_SM_0

MPUM7_SM_0

Periodical read-back of Arm ® Cortex ® -M7 configuration registers

End user

This method must be applied to Arm ® Cortex ® -M7 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.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UM2840 - Rev 1 page 21/132

UM2840

Hardware and software diagnostics

SM CODE

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

MPUM7_SM_0

Table 12. MPUM7_SM_1

SM CODE MPUM7_SM_1

Description

Ownership

Arm ® Cortex ® -M7 MPU software test.

End user .

Detailed implementation

Error reporting

Fault detection Time

This method tests Arm ® Cortex ® -M7 MPU capability to detect and report memory accesses violating the policy enforcement implemented by the MPU itself.

The implementation is based on intentionally performing memory accesses (in writing and read) to memory areas outside of the allowed by the MPU regions programming, and to collect and verify related generated error exceptions.

Test can be executed with the final MPU region programming or with a dedicated one.

Depends on implementation.

Depends on implementation.

Addressed Fault Model Permanent.

Dependency on device configuration None.

Initialization Depends on implementation.

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

On demand.

Not needed.

CPUM7_SM_0: Periodical core self test software

Startup execution of this safety mechanism is recommended for multiple fault mitigations - refer to

Section 4.1.3 Notes on multiple-fault scenario .

3.6.2

Arm ® Cortex ® -M4 CPU

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Table 13. CPUM4_SM_0

CPUM4_SM_0

Periodical core self-test software for Arm ® Cortex ® -M4 CPU

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

UM2840 - Rev 1 page 22/132

UM2840

Hardware and software diagnostics

SM CODE

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

CPUM4_SM_0

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 STM32H7 dual-core safety concept. CPU integrity is a key factor because 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.

SM CODE

Description

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

Table 14. CPUM4_SM_1

CPUM4_SM_1

Control flow monitoring in Application software

End user

A significant part of the failure distribution of Arm ® Cortex ® -M4 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:

Different internal states of the 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 the

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 and transient

None

Depends on implementation

Continuous

NA

-

CPUM4_SM_0: periodical core self-test software

UM2840 - Rev 1 page 23/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 15. CPUM4_SM_2

CPUM4_SM_2

Double computation in Application software

End user

A timing redundancy for safety-related computation is considered to detect transient faults affecting the Arm ® Cortex ® -M4 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

Depends on implementation

Depends on implementation

Transient

None

Depends on implementation

Continuous

Not needed

CPUM4_SM_0: periodical core self-test software

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.

SM CODE

Description

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

Table 16. CPUM4_SM_3

CPUM4_SM_3

Arm ® Cortex ® -M4 HardFault exceptions

ST

HardFault exception raise is an intrinsic safety mechanism implemented in Arm ® Cortex ® -M4 core, mainly dedicated 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.

High-priority interrupt event

Depends on implementation. Refer to functional documentation.

Permanent and transient

None

None

Continuous

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.

CPUM4_SM_0: periodical core self-test software

Enabling related interrupt generation on the detection of errors is highly recommended.

UM2840 - Rev 1 page 24/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 17. CPUM4_SM_4

Stack hardening for Application software

CPUM4_SM_4

End user

The stack hardening method is required to address faults (mainly transient) affecting

Arm ® Cortex ® -M4 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.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM4_SM_0: periodical core self-test software

This method partially overlaps with defensive programming techniques required by IEC 61508 for software development. Therefore in presence of Application software qualified for safety integrity greater or equal to SC2, optimizations are possible.

SM CODE

Description

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

Table 18. CPUM4_SM_7

CPUM4_SM_7

Memory protection unit ( MPU )

ST

The Arm ® Cortex ® -M4 CPU memory protection unit is able to detect illegal access to protected memory areas, according to criteria set by End user .

Exception raise (MemManage)

Refer to functional documentation

Systematic (software errors)

Permanent and transient (only program counter and memory access failures)

None

MPU registers must be programmed at start-up

On line

Not needed

MPU_SM_0: Periodical read-back of configuration registers

•

•

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

UM2840 - Rev 1 page 25/132

UM2840

Hardware and software diagnostics

SM CODE CPUM4_SM_7

• 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 not expected to be relevant for the safety concept of Device .

Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

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

Table 19. MPUM4_SM_0

MPUM4_SM_0

Periodical read-back of Arm ® Cortex ® -M4 MPU configuration registers

End user

This method must be applied to Arm ® Cortex ® -M4 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.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Table 20. MPUM4_SM_1

SM CODE MPUM4_SM_1

Description

Ownership

Arm ® Cortex ® -M4 MPU software test.

End user .

Detailed implementation

This method tests Arm ® Cortex ® -M4 MPU capability to detect and report memory accesses violating the policy enforcement implemented by the MPU itself.

The implementation is based on intentionally performing memory accesses (in writing and read) to memory areas outside of the allowed by the MPU regions programming, and to collect and verify related generated error exceptions.

Test can be executed with the final MPU region programming or with a dedicated one.

Depends on implementation.

Error reporting

Fault detection Time

Addressed Fault Model

Depends on implementation.

Permanent.

Dependency on device configuration None.

Initialization

Periodicity

Depends on implementation.

On demand.

Test for the diagnostic

Multiple faults protection

Not needed.

CPUM4_SM_0: Periodical core self test software

UM2840 - Rev 1 page 26/132

UM2840

Hardware and software diagnostics

SM CODE

Recommendations and known limitations

3.6.3

MPUM4_SM_1

Startup execution of this safety mechanism is recommended for multiple fault mitigations - refer to

Section 4.1.3 Notes on multiple-fault scenario .

CPUs-shared safety mechanisms

SM CODE

Description

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

Table 21. CPU_SM_5

CPU_SM_5

External watchdog

End user

Using an external watchdog linked to control flow monitoring method (refer to CPUM7_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 Safety requirement assumptions .

It also contributes to dramatically reduce potential common cause failures, because the external watchdog is clocked and supplied independently of Device .

Depends on implementation

Depends on implementation (watchdog timeout interval)

Permanent and transient

None

Depends on implementation

Continuous

To be defined at system level (outside the scope of Compliant item analysis)

CPUM7_SM_1, CPUM4_SM_1: control flow monitoring in Application software

CPU_SM_6: Internal watchdogs IWDG/WWDG

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).

It is worth to note that the use of an external watchdog could be needed anyway when the

Device is used to trigger final elements, in order to comply at system level with requirements from IEC61508-2:2010 Table A.1/Table A.14.

UM2840 - Rev 1 page 27/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 22. CPU_SM_6

CPU_SM_6

Internal watchdogs IWDG/WWDG

ST

Using the IDWG/WWDG watchdog linked to control flow monitoring method (refer to

CPUM7_SM_1) addresses failure mode of program counter or control structures of CPU .

Reset signal generation

Depends on implementation (watchdog timeout interval)

Permanent

None

IWDG/WWDG activation. It is recommended to use hardware watchdog in Option byte settings (IWDG/WWDG are automatically enabled after reset)

Continuous

WDG_SM_1: Software test for watchdog at startup

CPUM7_SM_1, CPUM4_SM_1: control flow monitoring in Application software

WDG_SM_0: periodical read-back of configuration registers

The IWDG/WWDG 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. Internal watchdog use is part of STM32H7

separation concept - refer to Section 3.2.5 The separation concept

and to CoU_15,16 for further information.

UM2840 - Rev 1 page 28/132

UM2840

Hardware and software diagnostics

Description

Ownership

Error reporting

Fault detection Time

Addressed Fault Model

Dependency on MCU configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

3.6.4

SM CODE

Detailed implementation

Recommendations and known limitations

Table 23. CPU_SM_11

CPU_SM_11

Cross-CPU safety information exchange

End user

•

•

A communication scheme for safety information between the two CPUs is implemented to allow the exchange of following information:

CPU integrity check status (i.e. the correct execution of CPUM7_SM_0, CPUM4_SM_0 on the related CPU)

Successful execution of each implemented software-based periodic safety mechanisms

Timestamp/frame counter mechanisms (or other equivalent) must be implemented to detect missing updates of the data and to avoid multiple data consumption.

Safety data must be exchanged on the shared SRAM area identified by CoU_11.

It is strongly recommended to use the HSEM module to support the implementation of data exchange.

Each CPU must force the safe state in case of a) failure reporting from the other CPU by messages b) wrong, incorrect, or missing message from the other CPU.

Depends on implementation

Depends on implementation

Permanent and Transient

N/A

Depends on implementation

Periodical

Not needed

CPUM7_SM_0: periodical core self-test software

CPUM4_SM_0: periodical core self-test software

This method can be used to implement CPU communications required by CoU_14, case b)

The main target of this method is to improve the separation concept (refer to

Section 3.2.5 The separation concept

), so its implementation could be recommended or not, depending on the architecture and CPU scheme selected. It must not be confused with DUAL_SM_0 which specifies communications between two different STM32H7 and not between CPUs of the same MCU.

Embedded Flash memory

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Table 24. FLASH_SM_0

FLASH_SM_0

Periodical software test for Flash memory

End user or ST

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).

Depends on implementation

UM2840 - Rev 1 page 29/132

UM2840

Hardware and software diagnostics

SM CODE

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

FLASH_SM_0

Depends on implementation

Permanent

Flash memory size changes according part number

Memory signatures must be stored in Flash memory as well

Periodic

Self-diagnostic capabilities can be embedded in the software, according the test implementation design strategy chosen

CPUM7_SM_0: Periodical core self-test software for Arm ® Cortex ® -M7 CPU

CPUM4_SM_0: Periodical core self-test software for Arm ® Cortex ® -M4 CPU

CPUM7_SM_1: control flow monitoring in application software

CPUM4_SM_1: control flow monitoring in application software

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 cyclic redundancy check (CRC) module is recommended. In principle direct memory access (DMA)

feature for data transfer can be used.

Unused Flash memory sections can be excluded from testing.

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.

As far as ASR2 requirement on PST duration (adoption of the same value for both CPUs) and

CoU_14 are correctly implemented, the overall Flash memory test can be partitioned among the two CPUs, or even delegated to only one.

SM CODE

Description

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

Table 25. FLASH_SM_1

FLASH_SM_1

Control flow monitoring in application software

End user

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 CPUM7_SM_1 and

CPUM4_SM_1.

Depends on implementation

Depends on implementation. Higher value is fixed by watchdog timeout interval.

Permanent and Transient

None

Depends on implementation

Continuous

NA

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

CPUM7_SM_1 and CPUM4_SM_1 correct implementation supersedes this requirement.

UM2840 - Rev 1 page 30/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 26. FLASH_SM_2

FLASH_SM_2

Arm ® Cortex ® -M7 and M4 HardFault exceptions

ST

Hardware random faults (both permanent and transient) affecting system Flash memory

(memory cells, address decoder) can lead to wrong instruction codes fetches, and eventually to the intervention of the Arm ® Cortex ® -M7 or Cortex ® -M4 HardFault exceptions. Refer to

CPUM7_SM_3 and CPUM4_SM_3 for detailed description.

Refer to CPUM7_SM_3 and CPUM4_SM_3

Refer to CPUM7_SM_3 and CPUM4_SM_3

Permanent and transient

None

Refer to CPUM7_SM_3 and CPUM4_SM_3

-

Continuous

-

CPUM7_SM_1, CPUM4_SM_1: control flow monitoring in application software

SM CODE

Description

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

Table 27. FLASH_SM_3

FLASH_SM_3

Option byte write protection

ST

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.

Write protection exception

Not applicable

None (Systematic only)

None

Not needed (enabled by default)

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

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.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Table 28. FLASH_SM_4

FLASH_SM_4

Static data encapsulation

End user

If static data are stored in Flash memory, encapsulation by a checksum field with encoding capability (such as CRC ) must be implemented.

Checksum validity is checked by application software before static data consuming.

Depends on implementation

UM2840 - Rev 1 page 31/132

UM2840

Hardware and software diagnostics

SM CODE

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

FLASH_SM_4

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

None

SM CODE

Description

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

Table 29. FLASH_SM_6

FLASH_SM_6

Flash memory unused area filling code

End user

Used Flash memory 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.

NA

NA

None (Fault avoidance)

None

NA

NA

NA

NA

Filling code can be made of NOP instructions, or an illegal code that leads to a HardFault exception raise.

UM2840 - Rev 1 page 32/132

UM2840

Hardware and software diagnostics

Table 30. FLASH_SM_7

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on

Initialization

Periodicity

Device

Test for the diagnostic

Multiple-fault protection

SM CODE

configuration

Recommendations and known limitations

FLASH_SM_7

ECC on Flash memory

ST

•

•

Internal Flash memory is protected by an ECC (Error Correction Code) redundancy, implementing a protection feature at double-word (64 bit) level:

One bit fault: correction

Two bits fault: detection

•

•

Correction:

Flag SNECCERR11/2 (ECC correction) is set in FLASH_SR1/2 register (FLASH_ECCR)

Interrupt is generated

•

•

•

Detection:

Flag DBECCERR1/2 (ECC detection) is set in FLASH_SR1/2 register

Bus error is generated

The address of the failing double word is saved in

FLASH_ECC_FA1/2R register.

ECC bits are checked during a memory reading

Permanent/Transient

None

None

Continuous

Direct test procedure for ECC efficiency is not available. ECC runtime hardware failures leading to the disable of such protection, or to wrong corrections, fall into a “multiple fault scenario” from

IEC 61508 perspective. Related failures are adequately mitigated by the combination of safety mechanisms reported in this table, field "Multiplefault protection". Read also the note on "Recommendations and known limitations" field.

•

•

•

•

FLASH_SM_0: Periodical software test for Flash memory

(1)

DIAG_SM_0: Periodical read-back of hardware diagnostics configuration registers

CPUM7_SM_3: Arm ® Cortex ® -M7 HardFault exceptions

CPUM4_SM_3: Arm ® Cortex ® -M4 HardFault exceptions

Enabling related interrupt generation on the detection of errors is highly recommended.

Note that because ECC is checked during memory reads, Flash section occupied by safety related program/data which are rarely accessed (for instance, code related to failures/errors management) are potentially exposed to the risk of error accumulation. In such a case, it is recommended to periodically check those locations with FLASH_SM_0 method.

Important note: because of the lack of ECC direct test procedure, single-fault failures leading to unintended ECC correction may cause an incorrect data read from Flash memory. This is why STM32H7 dual-core safety concept strongly recommends the adoption of multiple layers of overlapped safety mechanisms which collaborate to mitigate such kind of

ECC failures. Refer to

[1]

for further detailed information on ECC failures mitigation strategy.

1. The FMEDA snapshot document includes information on recommended frequency for FLASH_SM_0.

UM2840 - Rev 1 page 33/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 31. FLASH_SM_8

FLASH_SM_8

Read protection (RDP), Write protection (WRP), Proprietary code readout protection (PCROP)

ST

Flash memory can be protected against illegal reads or erase/write by using these protection features. The combination of these techniques and the related different protection level allows

End user to build an effective access protection policy.

Refer to functional documentation - in some cases an HardFault error is generated

Refer to functional documentation

Systematic

None

Not needed

Continuous

Not needed

Not needed

Hardware random-failure detection capability for Flash memory access policy is restricted to well-selected marginal failure modes, mainly affecting program counter and Flash memory interface functions. The associated diagnostic coverage is therefore expected to be not relevant in the framework of STM32H7 dual-core safety concept.

SM CODE

Description

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

3.6.5

Embedded SRAM

Table 32. FLASH_SM_9

FLASH_SM_9

Periodic test by software for Flash address decoder

ST or End user

Permanent faults affecting the system Flash interface address decoder are addressed through a dedicated software test that checks the memory cells contents versus the expected value.

Depends on implementation

Depends on implementation

Permanent

Flash memory density depends upon part number

Not needed

Periodical

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self-test software

Overlaps with FLASH_SM_0 implementation are possible

SM CODE

Description

Ownership

Table 33. RAM_SM_0

RAM_SM_0

Periodical software test for static random access memory (SRAM or RAM)

End user or ST

UM2840 - Rev 1 page 34/132

UM2840

Hardware and software diagnostics

SM CODE

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

RAM_SM_0

To enhance the coverage on SRAM data cells and to ensure adequate coverage for permanent faults affecting the address decoder it is required to execute a periodical software test on the system RAM memory. The selection of the algorithm must ensure the target SFF coverage for both the RAM cells and the address decoder. Evidences of the effectiveness of the coverage of the selected method must be also collected

Depends on implementation

Depends on implementation

Permanent

RAM size can change according to the part number

Depends on implementation

Periodic

Self-diagnostic capabilities can be embedded in the software, according the test implementation design strategy chosen

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Usage of a March test C- is recommended.

Because the nature of this test can be destructive, RAM contents restore must be implemented. Possible interferences with interrupt-serving routines fired during test execution must be also considered (such routines can access to RAM invalid contents).

Note: unused RAM section can be excluded by the testing, under End user responsibility on actual RAM usage by final application software.

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.

Test implementation must consider the constraints introduced by CoU_10. Accordingly, it is expected that each CPU tests its "private" SRAM partition and not the one allocated to the other CPU.

In case a destructive test is selected (e.g. March C-), the execution of the test on the shared memory defined by CoU_12 is not recommended, to avoid conflicts between the two CPUs.

SM CODE

Description

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

Table 34. RAM_SM_2

RAM_SM_2

Stack hardening for application software

End user

The stack hardening method is used to enhance the application software robustness to SRAM faults that affect the address decoder. The method is based on source code modification, introducing information redundancy in the stack-passed information to the called functions.

Method contribution is relevant in case the combination between the final application software structure and the compiler settings requires a significant use of the stack for passing function parameters.

Implementation is the same as method CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

Refer to CPUM7_SM_4, CPUM4_SM_4

UM2840 - Rev 1 page 35/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 35. RAM_SM_3

RAM_SM_3

Information redundancy for safety-related variables in application software

End user

To address transient faults affecting SRAM controller, it is required to implement information redundancy on the safety-related system variables stored in the RAM.

•

•

•

•

•

The guidelines for the implementation of this method are the following:

The system variables that are safety-related (in the sense that a wrong value due to a failure in reading on the RAM affects the safety functions) are well-identified and documented.

The arithmetic computation or decision based on such variables are executed twice and the two final results are compared.

Safety-related variables are stored and updated in two redundant locations, and comparison is checked before consuming data.

Enumerated fields must use non-trivial values, checked for coherence at least one time per PST

Data vectors stored in SRAM must be protected by a encoding checksum (such as

CRC )

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Implementation of this safety method shows a partial overlap with an already foreseen method

(CPUM7_SM_2, CPUM4_SM_2); optimizations in implementing both methods are therefore possible

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Table 36. RAM_SM_4

RAM_SM_4

Control flow monitoring in application software

End user

In case the End user application software is executed from SRAM, permanent and transient faults affecting the memory (cells and address decoder) can interfere with the program execution.

To address such failures it is needed to implement this method.

For more details on the implementation, refer to description CPUM7_SM_1, CPUM4_SM_1

Depends on implementation

Depends on implementation. Higher value is fixed by watchdog timeout interval.

Permanent and transient

None

Depends on implementation

Continuous

NA

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

UM2840 - Rev 1 page 36/132

UM2840

Hardware and software diagnostics

SM CODE

Recommendations and known limitations

RAM_SM_4

Needed just in case of application software execution from SRAM.

CPUM7_SM_1, CPUM4_SM_1 correct implementation supersedes this requirement

SM CODE

Description

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

Table 37. RAM_SM_5

RAM_SM_5

Periodical integrity test for application software in RAM

End user

In case application software or diagnostic libraries are executed in RAM, it is needed to protect the integrity of the code itself against soft-error corruptions and related code mutations. This method must check the integrity of the stored code by checksum computation techniques, on a periodic basis (at least once per PST ). For implementation details refer to similar method FLASH_SM_0

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

Periodic

Self-diagnostic capabilities can be embedded in the software, according the test implementation design strategy chosen.

CPUM7_SM_0, CPUM4_SM_0: periodical core self test software

CPUM7_SM_1, CPUM4_SM_1: control flow monitoring in application software

This method must be implemented only in case of application software or diagnostic libraries are executed from RAM

SM CODE

Description

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

Table 38. RAM_SM_6

RAM_SM_6

Read protection (RDP), Write protection (WRP)

ST

SRAM2 memory can be protected against illegal reads or erase/write by using these protection features. The combination of these techniques and the related different protection level allows End user to build an effective access protection policy

Refer to functional documentation - in some cases an HardFault error is generated

Refer to functional documentation

Systematic

SRAM2 size can vary depending on part number

Not needed

Continuous

Not needed

Not needed

Hardware random-failure detection capability for SRAM2 access policy is restricted to wellselected marginal failure modes, mainly affecting program counter and SRAM2 interface functions. The associated diagnostic coverage is therefore expected to be irrelevant in the framework of STM32H7 dual-core safety concept.

UM2840 - Rev 1 page 37/132

UM2840

Hardware and software diagnostics

Description

Ownership

Detailed implementation

SM CODE

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

Table 39. RAM_SM_7

RAM_SM_7

ECC on SRAM

ST

•

•

Internal SRAM is protected by an ECC (Error Correction Code) redundancy implementing a protection feature at double-word (64 bit) level:

One bit fault: correction

Two bits fault: detection

Refer to functional documentation

ECC bits are checked during a memory reading

Permanent/Transient

None

None

Continuous

Not needed

•

• RAM_SM_0: Periodical software test for Flash memory

DIAG_SM_0: Periodical read-back of hardware diagnostics configuration registers

The FMEDA snapshot document [2] includes information on

recommended frequency for RAM_SM_0.

SM CODE

Description

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

3.6.6

Table 40. RAM_SM_8

RAM_SM_8

Periodic test by software for SRAM address decoder

ST or End user

Permanent faults affecting the SRAM interfaces address decoder are addressed through a dedicated software test that checks the memory cells contents versus the expected value.

Depends on implementation

Depends on implementation

Permanent

SRAM size varies according to part number

Not needed

Periodical

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Overlaps with RAM_SM_0 implementation are possible.

System bus architecture/peripherals interconnect matrix

SM CODE

Description

Table 41. BUS_SM_0

BUS_SM_0

Periodical software test for interconnections

UM2840 - Rev 1 page 38/132

UM2840

Hardware and software diagnostics

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

BUS_SM_0

End user

The intra-chip connection resources (Bus Matrix, AHB or APB bridges) needs to be periodically tested for permanent faults detection. Note that STM32H7 dual-core devices have no hardware safety mechanism to protect these structures. The test executes a connectivity test of these shared resources, including the testing of the arbitration mechanisms between peripherals.

According to IEC 61508-2 Table A.8, A.7.4 the method is considered able to achieve high levels of coverage

Depends on implementation

Depends on implementation

Permanent

None

Depends on implementation

Periodic

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Implementation can be considered in large part as overlapping with the widely used Periodical read-back of configuration registers required for several peripherals

SM CODE

Description

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

Table 42. BUS_SM_1

BUS_SM_1

Information redundancy in intra-chip data exchanges

End user

This method requires to add some kind of redundancy (for example a CRC checksum at packet level) to each data message exchanged inside Device .

Message integrity is verified using the checksum by the application software, before consuming data.

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Implementation can be in large part overlapping with other safety mechanisms requiring information redundancy on data messages for communication peripherals. Optimizations are therefore possible.

SM CODE

Description

Ownership

Table 43. LOCK_SM_0

LOCK_SM_0

Lock mechanism for configuration options

ST

UM2840 - Rev 1 page 39/132

UM2840

Hardware and software diagnostics

SM CODE

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

LOCK_SM_0

The STM32H7 dual-core devices feature spread protection to prevent unintended configuration changes for some peripherals and system registers (for example PVD_LOCK, timers); the spread protection detects systematic faults in software application. The use of this method is encouraged to enhance the end application robustness to systematic faults.

Not generated (when locked, register overwrites are just ignored)

NA

None (Systematic only)

None

Depends on implementation

Continuous

Not needed

Not needed

No DC associated because this test addresses systematic faults

3.6.7

EXTI controller

Description

Ownership

SM CODE

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Table 44. NVIC_SM_0

NVIC_SM_0

Periodical read-back of configuration registers

End user

This test is implemented by executing a periodical check of the configuration registers for a system peripheral against its expected value. Expected values are previously stored in

RAM and adequately updated after each configuration change. The method mainly addresses transient faults affecting the configuration registers, by detecting bit flips in the registers contents. It addresses also permanent faults on registers because it is executed at least one time within PST after a peripheral update.

Method must be implemented to any configuration register whose contents are able to interfere with NVIC or EXTI behavior in case of incorrect settings. Check includes NVIC vector table.

According to the state-of-the-art automotive safety standard ISO26262, this method can achieve high levels of

diagnostic coverage (DC)

(refer to ISO26262:5, Table D.4)

•

•

•

An alternative valid implementation requiring less space in SRAM can be realized on the basis of signature concept:

Peripheral registers to be checked are read in a row, computing a CRC checksum (use of hardware CRC is encouraged)

Obtained signature is compared with the golden value (computed in the same way after each register update, and stored in SRAM)

Coherence between signatures is checked by the application software – signature mismatch is considered as failure detection

Depends on implementation

Depends on implementation

Permanent/transient

None

Values of configuration registers must be read after the boot before executing the first check

Periodic

Not applicable

CPUM7_SM_0, CPUM4_SM_0: Periodic core self-test software

UM2840 - Rev 1 page 40/132

UM2840

Hardware and software diagnostics

SM CODE

Recommendations and known limitations

NVIC_SM_0

This method addresses only failures affecting configuration registers, and not peripheral core logic or external interface.

Attention must be paid to registers containing mixed combination of configuration and status bits. Mask must be used before saving register contents affecting signature, and related checks, to avoid false positive detections.

Description

Ownership

SM CODE

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

Table 45. NVIC_SM_1

NVIC_SM_1

Expected and unexpected interrupt check

End user

According to IEC 61508-2 Table A.1 recommendations, a diagnostic measure for continuous, absence or cross-over of interrupt must be implemented. The method of expected and unexpected interrupt check is implemented at application software level.

•

•

•

•

•

The guidelines for the implementation of the method are the following:

The interrupts implemented on the MCU are well documented, also reporting, when possible, the expected frequency of each request (for example, the interrupts related to

ADC conversion completion that come on a regular basis).

Individual counters are maintained for each interrupt request served, in order to detect in a given time frame the cases of a) no interrupt at all b) too many interrupt requests

(“babbling idiot” interrupt source). The control of the time frame duration must be regulated according to the individual interrupt expected frequency.

Interrupt vectors related to unused interrupt source point to a default handler that reports, in case of triggering, a faulty condition (unexpected interrupt).

In case an interrupt service routine is shared between different sources, a plausibility check on the caller identity is implemented.

Interrupt requests related to non-safety-related peripherals are handled with the same method here described, despite their originator safety classification

Depends on implementation

Depends on implementation

Permanent/transient

None

Depends on implementation

Continuous

Not applicable

CPUM7_SM_0, CPUM4_SM_0: Periodic core selft-test software

In order to decrease the complexity of method implementation, it is suggested to use polling technique (when possible) instead of interrupt for end system implementation

UM2840 - Rev 1 page 41/132

UM2840

Hardware and software diagnostics

3.6.8

Direct memory access controllers (DMA, MDMA, BDMA and DMA request multiplexer

(DMAMUX))

SM CODE

Description

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

Table 46. DMA_SM_0

DMA_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to DMA configuration register and channel addresses register as well.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

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

Table 47. DMA_SM_1

DMA_SM_1

Information redundancy on data packet transferred via DMA

End user

This method is implemented adding to data packets transferred by DMA a redundancy check

(such as CRC check, or similar one) with encoding capability. Full data packet redundancy would be overkilling.

The checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet

Consistency of data packet must be checked by the application software before consuming data

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

To give an example about checksum encoding capability, using just a bit-by-bit addition is unappropriated

UM2840 - Rev 1 page 42/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 48. DMA_SM_2

DMA_SM_2

Information redundancy by including sender or receiver identifier on data packet transferred via DMA

End user

This method helps to identify inside the MCU the source and the originator of the message exchanged by DMA .

•

•

•

Implementation is realized by adding an additional field to protected message, with a coding convention for message type identification fixed at Device level. Guidelines for the identification fields are:

Identification field value must be different for each possible couple of sender or receiver on DMA transactions

Values chosen must be enumerated and non-trivial

Coherence between the identification field value and the message type is checked by application software before consuming data.

This method, when implemented in combination with DMA_SM_4, makes available a kind of

“virtual channel” between source and destinations entities.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

None

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Table 49. DMA_SM_3

DMA_SM_3

Periodical software test for DMA

End user

•

•

•

This method requires the periodical testing of the DMA basic functionality, implemented through a deterministic transfer of a data packet from one source to another (for example from memory to memory) and the checking of the correct transfer of the message on the target. Data packets are composed by non-trivial patterns (avoid the use of 0x0000, 0xFFFF values) and organized in order to allow the detection during the check of the following failures: incomplete packed transfer errors in single transferred word wrong order in packed transmitted data

Depends on implementation

Depends on implementation

Permanent

None

Depends on implementation

Periodic

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

UM2840 - Rev 1 page 43/132

UM2840

Hardware and software diagnostics

SM CODE

Recommendations and known limitations None

DMA_SM_3

SM CODE

Description

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

Table 50. DMA_SM_4

DMA_SM_4

DMA transaction awareness

End user

DMA transactions are non-deterministic by nature, because typically driven by external events like communication messages reception. Anyway, well-designed safety systems should keep much control as possible of events – refer for instance to IEC 61508-3 Table 2 item 13 requirements for software architecture.

This method is based on system knowledge of frequency and type of expected DMA transaction. For instance, an externally connected sensor supposed to send periodically some messages to a STM32 peripheral. Monitoring DMA transaction by a dedicated state machine allows to detect missing or unexpected DMA activities.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Because DMA transaction termination is often linked to an interrupt generation, implementation of this method can be merged with the safety mechanism NVIC_SM_1: expected and unexpected interrupt check.

3.6.9

Chrom-Art Accelerator controller (DMA2D)

SM CODE

Description

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

Table 51. DMA2D_SM_0

DMA2D_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to DMA2D configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UM2840 - Rev 1 page 44/132

Description

Ownership

Detailed implementation

SM CODE

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

UM2840

Hardware and software diagnostics

Table 52. DMA2D_SM_1

DMA2D_SM_1

Periodical software test for DMA2D functions

End user

This method requires the periodical testing of the DMA2D basic functionality, implemented through a deterministic transfer and processing of a set of “test images” from memory to memory and the checking of the correct execution (output image must be generated as per specifications).

Output image correctness can be performed by fast methods like CRC fingerprint computation.

•

•

•

•

•

Test definition must be able to cover following DMA2D basic functions:

Full image copy

Image filling with a specific color

Copy of part of the image

Pixel format conversion

Blending of two different images

Achieved diagnostic coverage on the module depends on the quantity and variance of tests performed.

Depends on implementation

Depends on implementation

Permanent

None

Depends on implementation

Periodic

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

In principle, DMA2D basic functions not used in the safety application can be excluded from this test suite implementation.

UM2840 - Rev 1 page 45/132

UM2840

Hardware and software diagnostics

Description

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

Note:

3.6.10

SM CODE

Table 53. DMA2D_SM_2

DMA2D_SM_2

DMA processing and interrupt awareness

End user

This method is based on system knowledge of frequency and type of

DMA2D transaction expected. In general, image processing systems are based on a deterministic timing for image framing arrival and processing.

Therefore, this method requires to monitor the expected execution of image processing and, in case interrupt generation is used, their correct timing and sequence.

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Implementation of this method can be merged with the safety mechanism

NVIC_SM_1: Expected and unexpected interrupt check

If image processing performed by DMA2D is used for the implementation of a safety function, system level considerations (as consistency checks on objects recognition results) may guarantee additional diagnostic coverage. Similarly, system level data redundancy schemes (as for instance algorithms based on processing for sequences of multiple image frames) may result in a relevant de rating for transient failure rate.

Hardware semaphore (HSEM)

SM CODE

Description

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

Table 54. HSEM_SM_0

HSEM_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to HSEM configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UM2840 - Rev 1 page 46/132

UM2840

Hardware and software diagnostics

Description

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

3.6.11

SM CODE

Table 55. HSEM_SM_1

HSEM_SM_1

Control flow monitoring for concurrent tasks

End user

This method is intended to monitor the correct execution of software tasks that use the HSEM semaphore method for their synchronization.

Method is implemented by software, leveraging on the presence of a system watchdog (internal or external).

Watchdog periodic reset function must be constrained to the correct timing execution of each software task synchronized by semaphores.

Depends on implementation

Depends on implementation. Higher value is fixed by watchdog timeout interval.

Permanent and Transient

None

Depends on implementation

Continuous

N/A

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Implementation must take into account potential overlaps/optimizations with CPUM7_SM_1, CPUM4_SM_1.

Single Wire Protocol Master Interface (SWPMI)

SM CODE

Description

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

Table 56. SWPMI_SM_0

SWPMI_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to SWPMI configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UM2840 - Rev 1 page 47/132

Description

Ownership

Detailed implementation

SM CODE

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

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

UM2840

Hardware and software diagnostics

Table 57. SWPMI_SM_1

SWPMI_SM_1

Protocol error signals and information redundancy including hardware

CRC

ST

SWPMI communication is based on a frame handling concept, composed by a combination of hardware synchronization signals, frame structure composition, hardware-computed CRC filed. This mechanism, mainly implemented to manage on-field communication disturbance, is able to achieve a relevant diagnostic coverage on several SWMPI module failure modes.

Error conditions are reported by flag bits in related registers

Depends on peripheral configuration and the type of violation detected, refer to functional documentation

Permanent and Transient

None

Depends on implementation

Continuous

N/A

SWPMI_SM_0: Periodical read-back of SWPMI configuration registers.

SWPMI_SM_2: SWMPI loopback test

This method is unable to address all IEC 61508 failure modes related to time handshake between parties (e.g. resequencing, repetition), leading to the introduction of SWPMI _SM_3.

Enabling related interrupt generation on the detection of errors is highly recommended.

Table 58. SWPMI_SM_2

SWPMI_SM_2

SWMPI loopback test

End user

By using the SWPMI module loopback function, it is possible to emulate the sending of SWPI frames and cross-checking the expected result in reception.

Error conditions are reported by flag bits in related registers

Depends on peripheral configuration and the type of violation detected, please refer to functional documentation

Permanent

None

Loopback mode must be enabled

Periodical

-

N/A

SWPMI_SM_0: Periodical read-back of SWPMI configuration registers.

UM2840 - Rev 1 page 48/132

Description

Ownership

Detailed implementation

SM CODE

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

UM2840

Hardware and software diagnostics

Table 59. SWPMI_SM_3

SWPMI_SM_3

Information redundancy techniques on messages to implement full endto-end operation

End user

This method aims to protect the communication between a peripheral and its external counterpart establishing a kind of “protected” channel. The aim is to specifically address communication failure modes as reported in

IEC 61508-2, 7.4.11.1.

•

•

•

Implementation guidelines are the following:

Additional field added in payload reporting an unique identification of sender/receiver and an unique increasing sequence packet number

Timing monitoring of the message exchange (for example check the message arrival within the expected time window), detecting therefore missed message arrival conditions

Application software must verify before consuming data packet its consistency (CRC check), its legitimacy (sender/receiver) and the correctness of sequence (sequence number check, no packets lost)

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

It is assumed that the remote SWMPI counterpart will have an equivalent capability of performing the checks described. This method is simplified by the existence of SWMPI_SM_1.

A major overlap between the requirements of this method and the implementation of security protection on the transaction is possible.

UM2840 - Rev 1 page 49/132

UM2840

Hardware and software diagnostics

3.6.12

FD controller area network (FDCAN)

Table 60. CAN_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

CAN_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to CAN configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

Table 61. CAN_SM_1

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

CAN_SM_1

Protocol error signals

ST

CAN communication module embeds protocol error checks (like error counters) conceived to detect network-related abnormal conditions. These mechanisms are able anyway to detect a marginal percentage of hardware random failures affecting the module itself.

Error signals connected to these checkers are normally handled in a standard communication software, so the overhead is reduced

Several error condition are reported by flag bits in related CAN registers.

Depends on peripheral configuration (for example baud rate), refer to functional documentation

Permanent and Transient

None

Initialization

Periodicity

Test for the diagnostic

Depends on implementation

Continuous

NA

Multiple faults protection CAN_SM_2: Information redundancy techniques on messages, including end-to-end protection

Recommendations and known limitations Enabling related interrupt generation on the detection of errors is highly recommended.

UM2840 - Rev 1 page 50/132

UM2840

Hardware and software diagnostics

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

3.6.13

Table 62. CAN_SM_2

CAN_SM_2

Information redundancy techniques on messages, including end-to-end protection.

End user

This method aims to protect the communication between a peripheral and his external counterpart establishing a kind of “protected” channel. The aim is to specifically address communication failure modes as reported in

IEC 61508-2, 7.4.11.1.

•

•

•

•

Implementation guidelines are the following:

Data packet must be protected (encapsulated) by an information redundancy check, like for instance a

CRC checksum computed over the packet and added to payload. Checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet.

Additional field added in payload reporting an unique identification of sender or receiver and an unique increasing sequence packet number

Timing monitoring of the message exchange (for example check the message arrival within the expected time window), detecting therefore missed message arrival conditions

Application software must verify before consuming data packet its consistency (CRC check), its legitimacy (sender or receiver) and the sequence correctness (sequence number check, no packets lost)

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Important note: it is assumed that the remote CAN counterpart has an equivalent capability of performing the checks described.

A major overlap between the requirements of this method and the implementation of complex communication software protocols can exists. Due to large adoption of these protocols in industrial applications, optimizations can be possible

Universal synchronous/asynchronous receiver/transmitter (USART 1/2/3/4/5/6/7/8, LPUART1)

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Table 63. UART_SM_0

UART_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to UART configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UM2840 - Rev 1 page 51/132

UM2840

Hardware and software diagnostics

SM CODE

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UART_SM_0

SM CODE

Description

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

Table 64. UART_SM_1

UART_SM_1

Protocol error signals

ST

USART communication module embeds protocol error checks (like additional parity bit check, overrun, frame error) conceived to detect network-related abnormal conditions. These mechanisms are able anyway to detect a marginal percentage of hardware random failures affecting the module itself.

Error signals connected to these checkers are normally handled in a standard communication software, so the overhead is reduced.

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration (for example baud rate), refer to functional documentation

Permanent and transient

None

Depends on implementation

Continuous

Not required

UART_SM_2: Information redundancy techniques on messages

USART communication module is fitted by several different configurations – the actual composition of communication error checks depends on selected configuration.

Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Table 65. UART_SM_2

UART_SM_2

Information redundancy techniques on messages

End user

This method is implemented adding to data packets transferred by UART a redundancy check

(like a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet.

Consistency of data packet must be checked by the application software before consuming data.

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

UM2840 - Rev 1 page 52/132

UM2840

Hardware and software diagnostics

SM CODE

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

UART_SM_2

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

It is assumed that the remote UART counterpart has an equivalent capability of performing the check described.

Transmission full redundancy (message repetition) should not be used because its detection capability is limited to a subset of communication unit failure modes.

To give an example on checksum encoding capability, using just a bit-by-bit addition is unappropriated.

SM CODE

Description

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

Table 66. UART_SM_3

UART_SM_3

Information redundancy techniques on messages, including end-to-end protection.

End user

This method aims to protect the communication between a peripheral and his external counterpart.

Refer to CAN_SM_2 description for detailed information.

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Important note: it is assumed that the remote UART counterpart has an equivalent capability of performing the checks described.

Refer to CAN_SM_2 for further notice.

UM2840 - Rev 1 page 53/132

UM2840

Hardware and software diagnostics

3.6.14

Inter-integrated circuit (I2C1/2/3/4)

SM CODE

Description

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

Table 67. IIC_SM_0

IIC_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to I2C configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

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

Table 68. IIC_SM_1

IIC_SM_1

Protocol error signals

ST

I2C communication module embeds protocol error checks (like overrun, underrun, packet error etc.) conceived to detect network-related abnormal conditions. These mechanisms are able anyway to detect a marginal percentage of hardware random failures affecting the module itself.

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration (for example baud rate), refer to functional documentation.

Permanent and transient

None

Depends on implementation

Continuous

Not needed

IIC_SM_2: Information redundancy techniques on messages

Adoption of SMBus option grants the activation of more efficient protocol-level hardware checks such as CRC-8 packet protection.

Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

Table 69. IIC_SM_2

IIC_SM_2

Information redundancy techniques on messages

UM2840 - Rev 1 page 54/132

UM2840

Hardware and software diagnostics

SM CODE

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device

Periodicity

configuration

Initialization

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

IIC_SM_2

End user

This method is implemented adding to data packets transferred by I2C a redundancy check

(such as a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet.

Consistency of data packet must be checked by the application software before consuming data.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

It is assumed that the remote I2C counterpart has an equivalent capability of performing the check described.

Transmission full redundancy (message repetition) should not be used because its detection capability is limited to a subset of communication unit failure modes.

To give an example on checksum encoding capability, using just a bit-by-bit addition is unappropriated.

This method is overlapped with IIC_SM_3 if hardware handled CRC insertion is possible.

SM CODE

Description

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

Table 70. IIC_SM_3

IIC_SM_3

CRC packet-level

ST

I2C communication module allows to activate for specific mode of operation (SMBus) the automatic insertion (and check) of CRC checksums to packet data.

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration (for example baud rate), refer to functional documentation.

Permanent and transient

None

Depends on implementation

Continuous

Not needed

IIC_SM_2: Information redundancy techniques on messages

This method can be part of the implementation for IIC_SM_2

Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

Table 71. IIC_SM_4

IIC_SM_4

Information redundancy techniques on messages, including end-to-end protection.

UM2840 - Rev 1 page 55/132

UM2840

Hardware and software diagnostics

SM CODE

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device

Initialization

Periodicity

configuration

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

IIC_SM_4

End user

This method aims to protect the communication between a I2C peripheral and his external counterpart.

Refer to CAN_SM_2 description for detailed information.

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Important note: it is assumed that the remote I2C counterpart has an equivalent capability of performing the checks described.

Refer to CAN_SM_2 for further notice.

3.6.15

Serial peripheral interface (SPI) 1/2/3/4/5/6

SM CODE

Description

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

Table 72. SPI_SM_0

SPI_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to SPI configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Table 73. SPI_SM_1

SPI_SM_1

Protocol error signals

ST

SPI communication module embeds protocol error checks (like overrun, underrun, timeout and so on) conceived to detect network-related abnormal conditions. These mechanisms are able anyway to detect a marginal percentage of hardware random failures affecting the module itself.

UM2840 - Rev 1 page 56/132

UM2840

Hardware and software diagnostics

SM CODE

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

SPI_SM_1

Error flag raise and optional interrupt event generation

Depends on peripheral configuration (for example baud rate), refer to functional documentation.

Permanent and transient

None

Depends on implementation

Continuous

NA

SPI_SM_2: Information redundancy techniques on messages

Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

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

Table 74. SPI_SM_2

SPI_SM_2

Information redundancy techniques on messages

End user

This method is implemented adding to data packets transferred by SPI a redundancy check

(such as a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet.

Consistency of data packet must be checked by the application software before consuming data.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

It is assumed that the remote SPI counterpart has an equivalent capability of performing the check described.

Transmission full redundancy (message repetition) should not be used because its detection capability is limited to a subset of communication unit failure modes.

To give an example on checksum encoding capability, using just a bit-by-bit addition is unappropriated.

This method is overlapped with SSP_SM_3 if hardware handled CRC insertion is possible.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Table 75. SPI_SM_3

SPI_SM_3

CRC packet-level

ST

SPI communication module allows to activate automatic insertion (and check) of CRC-8 or

CRC-18 checksums to packet data.

Error flag raise and optional Interrupt Event generation

UM2840 - Rev 1 page 57/132

UM2840

Hardware and software diagnostics

SM CODE

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

SPI_SM_3

Depends on peripheral configuration (for example baud rate), refer to functional documentation.

Permanent and transient

None

Depends on implementation

Continuous

Not needed

SPI_SM_2: Information redundancy techniques on messages

This method can be part of the implementation for SPI_SM_2

Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

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

Table 76. SPI_SM_4

SPI_SM_4

Information redundancy techniques on messages, including end-to-end protection.

End user

This method aims to protect the communication between SPI peripheral and his external counterpart.

Refer to CAN_SM_2 description for detailed information.

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Important note: it is assumed that the remote SPI counterpart has an equivalent capability of performing the checks described.

Refer to CAN_SM_2 for further notice.

UM2840 - Rev 1 page 58/132

UM2840

Hardware and software diagnostics

3.6.16

USB on-the-go high-speed (OTG_HS)

Table 77. USB_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

USB_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to USB configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

Table 78. USB_SM_1

SM CODE

Description

Ownership

Detailed implementation

USB_SM_1

Protocol error signals

ST

USB communication module embeds protocol error checks (like overrun, underrun, NRZI, bit stuffing etc.) conceived to detect network-related abnormal conditions. These mechanisms are able anyway to detect a marginal percentage of hardware random failures affecting the module itself

Error flag raise and optional Interrupt Event generation Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Depends on peripheral configuration (for example baud rate), refer to functional documentation

Permanent and Transient

None

Depends on implementation

Continuous

Test for the diagnostic

Multiple faults protection

Not needed

USB_SM_2: Information redundancy techniques on messages

Recommendations and known limitations Enabling related interrupt generation on the detection of errors is highly recommended.

UM2840 - Rev 1 page 59/132

UM2840

Hardware and software diagnostics

Table 79. USB_SM_2

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

USB_SM_2

Information redundancy techniques on messages

ST or End user

The implementation of required information redundancy on messages, USB communication module is fitted by hardware capability. It basically allows to activate the automatic insertion (and check) of

CRC checksums to packet data.

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration (for example baud rate), refer to functional documentation

Permanent and Transient

None

Initialization

Periodicity

Test for the diagnostic

Error reporting configuration, if interrupt events are planned

Continuous

Not needed

Multiple faults protection USB_SM_2: Information redundancy techniques on messages

Recommendations and known limitations None

Table 80. USB_SM_3

SM CODE USB_SM_3

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Information redundancy techniques on messages, including end-to-end protection.

End user

This method aims to protect the communication between an USB peripheral and his external counterpart.

Refer to CAN_SM_2 description for detailed information

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Test for the diagnostic

Multiple faults protection

Refer to CAN_SM_2

Refer to CAN_SM_2

Recommendations and known limitations

This method apply in case USB bulk or isochronous transfers are used. For other transfers modes the USB hardware protocol already implements several features of this requirement.

Refer to CAN_SM_2 for further notice

UM2840 - Rev 1 page 60/132

UM2840

Hardware and software diagnostics

3.6.17

Analog-to-digital converters (ADC)

Table 81. ADC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

ADC_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to ADC configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

Table 82. ADC_SM_1

SM CODE

Description

Ownership

Detailed implementation

ADC_SM_1

Multiple acquisition by application software

End user

This method implements a timing information redundancy by executing multiple acquisitions on the same input signal. Multiple acquisition data are then combined by a filter algorithm to determine the signal correct value

Depends on implementation Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Depends on implementation

Permanent and Transient

None

Depends on implementation

Continuous

Test for the diagnostic

Multiple faults protection

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Recommendations and known limitations

It is highly probable that this recommendation is satisfied by design by the End user application software. Usage of multiple acquisitions followed by average operations is a common technique in industrial applications where it is needed to survive with spurious EMI disturbs on sensor lines

UM2840 - Rev 1 page 61/132

UM2840

Hardware and software diagnostics

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 83. ADC_SM_2

ADC_SM_2

Range check by application software

End user

•

•

•

The guidelines for the implementation of the method are the following:

The expected range of the data to be acquired are investigated and adequately documented. Note that in a well-designed application it is improbable that during normal operation an input signal has a very near or over the upper and lower rail limit (saturation in signal acquisition).

If the application software is aware of the state of the system, this information is to be used in the range check implementation. For example, if the ADC value is the measurement of a current through a power load, reading an abnormal value such as a current flowing in opposite direction versus the load supply may indicate a fault in the acquisition module.

As the ADC module is shared between different possible external sources, the combination of plausibility checks on the different signals acquired can help to cover the whole input range in a very efficient way

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

The implementation (and the related diagnostic efficiency) of this safety mechanism are strongly applicationdependent

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 84. ADC_SM_3

ADC_SM_3

Periodical software test for ADC

End user

•

•

The method is implemented acquiring multiple signals and comparing the read value with the expected one, supposed to be know. Method can be implemented with different level of complexity:

Basic complexity: acquisition and check of upper or lower rails (VDD or VSS) and internal reference voltage

High complexity: in addition to basic complexity tests, acquisition of a DAC output connected to ADC input and checking all voltage excursion and linearity

Depends on implementation

Depends on implementation

Permanent

None

Depends on implementation

Periodic

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Combination of two different complexity method can be used to better optimize test frequency in high demand safety functions

UM2840 - Rev 1 page 62/132

UM2840

Hardware and software diagnostics

Table 85. ADC_SM_4

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

ADC_SM_4

1oo2 scheme for ADC inputs

End user

This safety mechanism is implemented using two different SAR ADC channels belonging to separate ADC modules to acquire the same input signal. The application software checks the coherence between the two readings.

Depends on implementation

Depends on implementation

Permanent and Transient

None

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Depends on implementation

On demand

Not needed

ADC_SM_0: Periodical read-back of ADC configuration registers

Recommendations and known limitations

This method can be used in conjunction with ADC_SM_0/ ADC_SM_2/ ADC_SM_3 to achieve highest level of ADC module diagnostic coverage

UM2840 - Rev 1 page 63/132

UM2840

Hardware and software diagnostics

3.6.18

Digital-to-analog converter (DAC)

SM CODE

Description

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

Table 86. DAC_SM_0

DAC_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to DAC configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 87. DAC_SM_1

DAC_SM_1

DAC output loopback on ADC channel

End user

Implementation is realized by routing the active DAC output to one ADC channel, and by checking the output current value with his expected one.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

Continuous or on demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Efficiency versus transient failures is linked to final application characteristics. We define as

Tm the minimum duration of DAC wrong signal permanence required to violate the related safety function(s). Efficiency is maximized when execution test frequency is higher than 1/Tm.

UM2840 - Rev 1 page 64/132

UM2840

Hardware and software diagnostics

3.6.19

Basic timers TIM 6/7

Table 88. GTIM_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

GTIM_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to basic counter timer TIM6 or TIM7 configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 89. GTIM_SM_1

GTIM_SM_1

1oo2 for counting timers

End user

This method implements via software a 1oo2 scheme between two counting resources.

•

•

•

The guidelines for the implementation of the method are the following:

Two timers are programmed with same time base or frequency.

In case of timer use as a time base: use in the application software one of the timer as time base source, and the other one just for check. Coherence check for the 1oo2 is done at application level, comparing two counters values each time the timer value is used to affect safety function.

In case of interrupt generation usage: use the first timer as main interrupt source for the service routines, and use the second timer as a “reference” to be checked at the initial of interrupt routine

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Tolerance implementation in timer checks is recommended to avoid false positive outcomes of the diagnostic

UM2840 - Rev 1 page 65/132

UM2840

Hardware and software diagnostics

3.6.20

Note:

Advanced, general, high resolution and low ‑ power timers (TIM1/2/3/4/5/8/12/13/14/15/16/17,

HRTIM and LPTIM)

As the timers are equipped with many different channels, each independent from the others, and possibly programmed to realize different features, the safety mechanism is selected individually for each channel.

Table 90. ATIM_SM_0

SM CODE

Description

Ownership

Detailed implementation

ATIM_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to advanced, general, high resolution and low ‑ power timers

(TIM1/2/3/4/5/8/12/13/14/15/16/17, HRTIM and LPTIM) configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Periodicity

Test for the diagnostic

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Multiple faults protection Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

UM2840 - Rev 1 page 66/132

UM2840

Hardware and software diagnostics

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 91. ATIM_SM_1

ATIM_SM_1

1oo2 for counting timers

End user

This method implements via software a 1oo2 scheme between two counting resources.

•

•

•

The guidelines for the implementation of the method are the following:

Two timers are programmed with same time base or frequency.

In case of timer use as a time base: use in the application software one of the timer as time base source, and the other one just for check. Coherence check for the 1oo2 is done at application level, comparing two counters values each time the timer value is used to affect safety function.

In case of interrupt generation usage: use the first timer as main interrupt source for the service routines, and use the second timer as a “reference” to be checked at the initial of interrupt routine

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Tolerance implementation in timer checks is recommended to avoid false positive outcomes of the diagnostic.

This method apply to timer channels merely used as elapsed time counters

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 92. ATIM_SM_2

ATIM_SM_2

1oo2 for input capture timers

End user

This method is conceived to protect timers used for external signal acquisition and measurement, like “input capture” and “encoder reading”. Implementation requires to connect the external signals also to a redundant timer, and to perform a coherence check on the measured data at application level.

Coherence check between timers is executed each time the reading is used by the application software

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

To reduce the potential effect of common cause failures, it is suggested to use for redundant check a channel belonging to a different timer module and mapped to non-adjacent pin on the device package

UM2840 - Rev 1 page 67/132

UM2840

Hardware and software diagnostics

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 93. ATIM_SM_3

ATIM_SM_3

Loop-back scheme for PWM outputs

End user

This method is implemented by connecting the PWM to a separate timer channel to acquire the generated waveform characteristics.

•

•

The guidelines are the following:

Both PWM frequency and duty cycle are measured and checked versus the expected value.

To reduce the potential effect of common cause failure, it is suggested to use for the loopback check a channel belonging to a different timer module and mapped to non-adjacent pins on the device package.

This measure can be replaced under the End user responsibility by different loopback schemes already in place in the final application and rated as equivalent. For example if the PWM is used to drive an external power load, the reading of the on-line current value can be used instead of the PWM duty cycle measurement.

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Efficiency versus transient failures is linked to final application characteristics. We define as Tm the minimum duration of PWM wrong signal permanence (wrong frequency, wrong duty, or both) required to violate the related safety function(s). Efficiency is maximized when execution test frequency is higher than 1/Tm

Table 94. ATIM_SM_4

SM CODE ATIM_SM_4

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Lock bit protection for timers

ST

This safety mechanism allows the End user to lock down specified configuration options, avoiding unintended modifications by application software. It addresses therefore software development systematic faults

NA

NA

None (Fault avoidance)

None

Initialization

Periodicity

Lock protection must be enabled using LOCK bits in the TIMx_BDTR register

Continuous

Test for the diagnostic NA

Multiple faults protection NA

Recommendations and known limitations This method does not addresses timer configuration changes due to soft-errors

Note: IRTIM is not individually mentioned here, being mainly implemented by TIM16 and TIM17 functions. Refer therefore to related prescriptions.

UM2840 - Rev 1 page 68/132

UM2840

Hardware and software diagnostics

3.6.21

General-purpose input/output (GPIO) - Port A/B/C/D/E/F/G/H/I/J/K

SM CODE

Description

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

Table 95. GPIO_SM_0

GPIO_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to GPIO configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

GPIO availability can differ according to part number

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

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

Table 96. GPIO_SM_1

GPIO_SM_1

1oo2 for input GPIO lines

End user

This method addresses GPIO lines used as inputs. Implementation is done by connecting the external safety-related signal to two independent GPIO lines. Comparison between the two GPIO values is executed by application software each time the signal is used to affect application software behavior.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

•

•

•

To reduce the potential impact of common cause failure, it is recommended to use GPIO lines: belonging to different I/O ports (for instance port A and B) with different bit port number (for instance PA1 and PB5) mapped to non-adjacent pins on the device package

SM CODE

Description

Table 97. GPIO_SM_2

Loopback scheme for output GPIO lines

GPIO_SM_2

UM2840 - Rev 1 page 69/132

UM2840

Hardware and software diagnostics

SM CODE

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device

Periodicity

configuration

Initialization

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

GPIO_SM_2

End user

This method addresses GPIO lines used as outputs. Implementation is done by a loopback scheme, connecting the output to a different GPIO line programmed as input and by using the input line to check the expected value on output port. Comparison is executed by application software periodically and each time output is updated.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

•

•

•

To reduce the potential impact of common cause failure, it is recommended to use GPIO lines: belonging to different I/O ports (for instance port A and B) with different bit port number (for instance PA1 and PB5) mapped to non-adjacent pins on the device package

Efficiency versus transient failures is linked to final application characteristics. We define as

Tm the minimum duration of GPIO output wrong signal permanence required to violate the related safety function(s). Efficiency is maximized when execution test frequency is higher than 1/Tm.

SM CODE

Description

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

Table 98. GPIO_SM_3

GPIO_SM_3

GPIO port configuration lock register

ST

This safety mechanism prevents configuration changes for GPIO registers; it addresses therefore systematic faults in software application.

The use of this method is encouraged to enhance the end-application robustness for systematic faults.

Depends on implementation

Depends on implementation

None (Systematic only)

None

Application software must apply a correct write sequence to LCKK bit (bit 16 of the

GPIOx_LCKR register) after writing the final GPIO configuration.

Continuous

Not needed

Not needed

This method does not address transient faults (soft errors) that can possibly cause bit-flips on

GPIO registers at running time.

UM2840 - Rev 1 page 70/132

UM2840

Hardware and software diagnostics

3.6.22

Real-time clock module (RTC)

SM CODE

Description

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

Table 99. RTC_SM_0

RTC_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to RTC configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Table 100. RTC_SM_1

RTC_SM_1

Application check of running RTC

End user

The application software implements some plausibility check on RTC calendar or timing data, mainly after a power-up and further date reading by RTC.

•

•

•

•

The guidelines for the implementation of the method are the following:

RTC backup registers are used to store coded information in order to detect the absence of VBAT during power-off period.

RTC backup registers are used to periodically store compressed information on current date or time

The application software executes minimal consistence checks for date reading after power-on (detecting “past” date or time retrieve).

Application software periodically checks that RTC is actually running, by reading RTC timestamp progress and comparing with an elapsed time measurement based on

STM32 internal clock or timers.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

Periodical

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

UM2840 - Rev 1 page 71/132

UM2840

Hardware and software diagnostics

SM CODE

Recommendations and known limitations

RTC_SM_1

This method provides a limited diagnostic coverage for RTC failure modes. In case of End user application where RTC timestamps accuracy can affect in severe way the safety function

(for example, medical data storage devices), it is strongly recommended to adopt more efficient system-level measures.

Table 101. RTC_SM_2

SM CODE RTC_SM_2

Description

Ownership

Detailed implementation

Information redundancy on backup registers

End user

Data stored in RTC backup registers must be protected by a checksum with encoding capability

(for instance, CRC). Checksum must be checked by application software before consuming stored data.

This method guarantees data versus erases due to backup battery failures

Depends on implementation Error reporting

Fault detection time

Addressed fault model

Dependency on

Initialization

Device configuration

Depends on implementation

Permanent and Transient

None

Depends on implementation

Periodicity

Test for the diagnostic

Multiple-fault protection

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Recommendations and known limitations None

SM CODE

Description

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

Table 102. RTC_SM_3

RTC_SM_3

Application-level measures to detect failures in timestamps/event capture

End user

This method must detect failures affecting the RTC capability to correct execute the timestamps/event capture functions. Due to the nature strictly application-dependent of this solution, no detailed guidelines for its implementation are given here.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

Periodic / On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self-test software

This method must be used only if the timestamps/event capture function is used in the safety function implementation. It is worth noting that the use of timestamp / event capture in safety-related applications with the MCU in Sleep or Stop mode is prevented by the assumed requirement ASR7 (refer to

Section 3.3.1 Safety requirement assumptions

).

UM2840 - Rev 1 page 72/132

UM2840

Hardware and software diagnostics

3.6.23

Power controller (PWR)

Table 103. VSUP_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

VSUP_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 104. VSUP_SM_1

VSUP_SM_1

Supply voltage internal monitoring (PVD)

ST

The device features an embedded programmable voltage detector (PVD) that monitors the VDD power supply and compares it to the VPVD threshold. An interrupt can be generated when VDD drops below the VPVD threshold or when VDD is higher than the VPVD threshold

Interrupt Event generation

Depends on threshold programming, refer to functional documentation

Permanent and Transient

None

Protection enable by PVDE bit and threshold programming in Power control register (PWR_CR)

Continuous

Not needed

DIAG_SM_0: Periodical read-back of hardware diagnostics configuration registers

Internal monitoring PVD has limited capability to address failures affecting STM32H7 dual-core internal voltage regulator. Refer to device FMEA for details

Enabling related interrupt generation on the detection of errors is highly recommended.

UM2840 - Rev 1 page 73/132

UM2840

Hardware and software diagnostics

Table 105. VSUP_SM_2

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

VSUP_SM_2

External watchdog

End user

Failures in the power supplies for digital logic (core or peripherals) may lead to alteration of the application software timing, which can be detected by the external watchdog as safety mechanism introduced to monitor the application software control flow. Refer to CPU_SM_5 for further information.

Refer to CPU_SM_5

Refer to CPU_SM_5

Refer to CPU_SM_5

Refer to CPU_SM_5

Initialization

Periodicity

Refer to CPU_SM_5

Refer to CPU_SM_5

Test for the diagnostic Refer to CPU_SM_5

Multiple faults protection Refer to CPU_SM_5

Recommendations and known limitations Refer to CPU_SM_5

Table 106. VSUP_SM_3

SM CODE

Description

Ownership

Detailed implementation

VSUP_SM_3

Internal temperature sensor check

End user

The internal temperature sensor must be periodically tested in order to detect abnormal increase of the die temperature – hardware faults in supply voltage system may cause excessive power consumption and consequent temperature rise

Depends on implementation Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Depends on implementation

Permanent

None

None

Periodic

Test for the diagnostic

Multiple faults protection

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Recommendations and known limitations

This method also mitigates the eventuality of common-cause affecting the MCU and due to too high temperature.

Refer to the device datasheet to set the threshold temperature

UM2840 - Rev 1 page 74/132

UM2840

Hardware and software diagnostics

Table 107. VSUP_SM_5

SM CODE

Description

Ownership

Detailed implementation

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

VSUP_SM_5

System-level power supply management

End user

•

•

•

This method is implemented at system level in order to guarantee the stability of power supply value over time. It can include a combination of different overlapped solutions, some listed here below (but not limited to):

Additional voltage monitoring by external components

Passive electronics devices able to mitigate overvoltage

Specific design of power regulator in order to avoid power supply perturbation in presence of a single failure

Depends on implementation

Fault avoidance

None

Depends on implementation

Periodicity

Test for the diagnostic

Continuous

N/A

Multiple faults protection N/A

Recommendations and known limitations

Usually this method is already required/implemented to guarantee the stability of each component of the final electronic board

3.6.24

Reset and clock controller (RCC)

SM CODE

Description

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

Table 108. CLK_SM_0

CLK_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to configuration registers for clock and reset system (refer to

RCC register map).

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Table 109. CLK_SM_1

SM CODE

Description Clock security system (CSS)

CLK_SM_1

UM2840 - Rev 1 page 75/132

UM2840

Hardware and software diagnostics

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

CLK_SM_1

ST

•

•

•

The clock security system (CSS) detects the loss of high-speed external (HSE) oscillator clock activity and executes the corresponding recovery action, such as:

Switch-off HSE

Commutation on the HSI

Generation of related NMI

NMI

Depends on implementation (clock frequency value).

Permanent and transient

None

CSS protection must be enabled through Clock interrupt register (RCC_CIR) after boot stabilization.

Continuous

CLK_SM_0: periodical read-back of configuration registers

CPU_SM_5: external watchdog

It is recommended to carefully read reference manual instruction on NMI generation, in order to correctly managing the faulty situation by Application software .

SM CODE

Description

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

Table 110. CLK_SM_2

CLK_SM_2

External watchdog

ST

The external watchdog is able to detect failures in internal main MCU clock (lower frequency).

Refer to CPU_SM_5 for further details.

Depends on implementation

Depends on implementation (watchdog timeout interval).

Permanent

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_1, CPUM4_SM_1: control flow monitoring in application software

If a time window function option is used, End user must consider possible tolerance in application software execution, to avoid false error reports (affecting system availability).

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Table 111. CLK_SM_3

CLK_SM_3

Internal clock cross-measure

End user

This method is implemented using TIM14 capabilities to be fed by the 32 KHz RTC clock or an external clock source (if available). TIM14 counter progresses are compared with another counter (fed by internal clock). Abnormal values of oscillator frequency can therefore be detected.

Depends on implementation

UM2840 - Rev 1 page 76/132

UM2840

Hardware and software diagnostics

SM CODE

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

CLK_SM_3

Depends on implementation

Permanent

None

Depends on implementation

Periodic

Not needed

CPUM7_SM_1, CPUM4_SM_1: control flow monitoring in application software

CPU_SM_5: external watchdog

Efficiency versus transient faults is negligible. It provides only medium efficiency in permanent clock-related failure mode coverage.

3.6.25

Independent watchdog (IWDG), system window watchdog (WWDG)

SM CODE

Description

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

Table 112. WDG_SM_0

WDG_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to IWDG/WWDG configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Table 113. WDG_SM_1

WDG_SM_1

Software test for IWDG/WWDG watchdogs at startup

End user

This safety mechanism ensures the right functionality of the internal watchdogs in use. At startup, the software test programs the watchdog with the required expiration timeout, stores a specific non-trivial code in SRAM and waits for the reset signal. After the watchdog reset, the software understands that the watchdog has correctly triggered, and does not execute the procedure again. IWDG and WWDG must be individually tested.

Depends on implementation

Depends on implementation

Permanent

None

UM2840 - Rev 1 page 77/132

UM2840

Hardware and software diagnostics

SM CODE

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

WDG_SM_1

Depends on implementation

Startup (see below)

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

In a typical End user application, this test can be executed only at startup and during maintenance or offline periods. It could be associated to IEC 61508 concept of “proof test” and so it cannot be accounted for a diagnostic coverage contribution during operating time.

3.6.26

3.6.27

Clock recovery system (CRS)

No safety mechanisms are defined for CRS because of the consequences of CoU_8 (refer to Table 175. List of safety recommendations ). CRS disactivation is guaranteed by

Section 3.6.50 Disable and periodic cross-check of unintentional activation of unused peripherals .

Debug support (DBG)

SM CODE

Description

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

Table 114. DBG_SM_0

DBG_SM_0

Independent watchdog

ST

The debug unintentional activation due to hardware random fault results in the massive disturbance of CPU operations, leading to intervention of the independent watchdog or alternately, the other system watchdog WWGDG or an external one.

Reset signal generation

Depends on implementation (watchdog timeout interval).

Permanent

None

Depends on implementation

Continuous

Not needed

CPUM7_SM_1, CPUM4_SM_1: control flow monitoring in application software

None

UM2840 - Rev 1 page 78/132

UM2840

Hardware and software diagnostics

3.6.28

Cyclic redundancy-check module (CRC)

Table 115. CRC_SM_0

SM CODE

Description

Ownership

Detailed implementation

CRC_SM_0

CRC self-coverage

ST

The CRC algorithm implemented in this module (CRC-32 Ethernet polynomial: 0x4C11DB7) offers excellent features in terms of error detection in the message. Therefore permanent and transient faults affecting CRC computations are easily detected by any operations using the module to recompute an expected signature

Depends on implementation Error reporting

Fault detection time

Addressed fault model

Dependency on

Initialization

Device configuration

Depends on implementation

Permanent and Transient

None

Depends on implementation

Periodicity

Test for the diagnostic

Multiple faults protection

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Recommendations and known limitations None

3.6.29

System configuration controller (SYSCFG)

SM CODE

Description

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

Table 116. SYSCFG_SM_0

SYSCFG_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to System Configuration controller configuration registers.

This method is strongly recommended to protect registers related to hardware diagnostics activation and error reporting chain related features.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

This method is mainly overlapped by several other “configuration register read-backs” required for other MCU peripherals. It is reported here for the sake of completeness.

UM2840 - Rev 1 page 79/132

UM2840

Hardware and software diagnostics

SM CODE

Description

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

Table 117. DIAG_SM_0

DIAG_SM_0

Periodical read-back of hardware diagnostics configuration registers

End user

•

•

In STM32H7 dual-core several hardware-based safety mechanisms are available (they are reported in this manual with the wording Ownership=ST). This method must be applied to any configuration register related to diagnostic measure operations, including error reporting. End user must therefore individuate configuration registers related to:

Hardware diagnostic enable

Interrupt/NMI enable (if used for diagnostic error management)

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

3.6.30

SD/SDIO/MMC card host interface (SDMMC)

Table 118. SDIO_SM_0

Description

Ownership

SM CODE

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

SDIO_SM_0

Periodical read-back of SDIO/SMMC configuration registers

End user

This method must be applied to SDIO/SMMC configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

Description

Ownership

SM CODE

Table 119. SDIO_SM_1

SDIO_SM_1

Protocol error signals including hardware CRC

ST

UM2840 - Rev 1 page 80/132

UM2840

Hardware and software diagnostics

SM CODE SDIO_SM_1

Detailed implementation

Error reporting

Fault detection time

SDIO/SMMC communication module embeds protocol error checks (like overrun, underrun, timeout etc.) and CRC-packet checks as well, conceived to detect network-related abnormal conditions.

These mechanisms are able anyway to detect a percentage of hardware random failures affecting the module itself

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration (for example baud rate), please refer to functional documentation

Permanent and transient

None

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Depends on implementation

Continuous

Test for the diagnostic N/A

Multiple faults protection SDIO_SM_2: Information redundancy techniques on messages

Recommendations and known limitations Enabling related interrupt generation on the detection of errors is highly recommended.

Table 120. SDIO_SM_2

Description

Ownership

SM CODE

Detailed implementation

SDIO_SM_2

Information redundancy techniques on messages

End user

This method is implemented adding to data packets transferred by SDIO/SMMC a redundancy check

(like a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet.

Consistency of data packet must be checked by the application software before consuming data

Depends on implementation Error reporting

Fault detection time

Addressed fault model

Depends on implementation

Permanent and Transient

Dependency on Device configuration None

Initialization Depends on implementation

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

To give an example on checksum encoding capability, using just a bit-by-bit addition is unappropriated.

This safety mechanism can overlap with information redundancy techniques implemented at system level to address failure of physical device connected to SDIO/SMMMC port

Note: The safety mechanisms mentioned above are addressing the SDIO/SMMC interface included in STM32 MCUs.

No claims are done in this Safety Manual about the mitigation of hardware random faults affecting the external memory connected to SDIO/SMMC port.

UM2840 - Rev 1 page 81/132

UM2840

Hardware and software diagnostics

3.6.31

SM CODE

Description

Ownership

Flexible static memory controller (FSMC)

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 121. FSMC_SM_0

FSMC_SM_0

Control flow monitoring in application software

End user

If FSMC is used to connect an external memory containing software code to be executed by the

CPU, permanent and transient faults affecting the FSMC memory controller are able to interfere with the access operation by the CPU, leading to wrong data or instruction fetches. A strong control flow mechanism linked to a system watchdog is able to detect such failures, in case they interfere with the expected flow of the application software.

The implementation of this method is identical to the one reported for CPUM7_SM_1, CPUM4_SM_1, refer there for details

Depends on implementation

Depends on implementation. Higher value is fixed by watchdog timeout interval

Permanent and Transient

FSMC interface is available only on selected part numbers

Depends on implementation

Continuous

N/A

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

This mechanism must be used just if FSMC external memory is used to store executable programs

Table 122. FSMC_SM_1

SM CODE FSMC_SM_1

Description

Ownership

Detailed implementation

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Information redundancy on external memory connected to FSMC

End user

If FSMC interface is used to connect an external memory where safety-relevant data are stored, information redundancy techniques for stored data are able to address faults affecting the FSMC interface. The possible techniques are:

To use redundant copies of safety relevant data and perform coherence check before consuming.

To organize data in arrays and compute the checksum field to be checked before use

Error reporting

Fault detection time

Depends on implementation

Depends on implementation

Addressed fault model Permanent and Transient

Dependency on Device configuration FSMC interface is available only on selected part numbers

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

This mechanism must be used just if FSMC external memory is used to store safety-related data.

This safety mechanism can overlap with information redundancy techniques implemented at system level to address failure of physical device connected to FSMC port

UM2840 - Rev 1 page 82/132

UM2840

Hardware and software diagnostics

Table 123. FSMC_SM_2

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

FSMC_SM_2

Periodical read-back of FSMC configuration registers

End user

This method must be applied to FSMC configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

FSMC interface is available only on selected part numbers

Initialization

Periodicity

Refer to NVIC_SM_0

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

Table 124. FSMC_SM_3

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

FSMC_SM_3

ECC engine on NAND interface in FSMC module

ST

The FMC NAND Card controller includes two error correction code computation hardware blocks, one per memory bank. They reduce the host CPU workload when processing the ECC by software.

ECC mechanism protects data integrity on the external memory connected to NAND port

Refer to functional documentation

ECC bits are checked during a memory reading

Permanent and Transient

FSMC interface is available only on selected part numbers

Initialization

Periodicity

None

Continuous

Test for the diagnostic Not needed

Multiple faults protection

Recommendations and known limitations

FSMC_SM_2: Periodical read-back of FSMC configuration registers

This method has negligible efficiency in detecting hardware random failures affecting the FSMC interface. It can be part of End user safety concept because addressing memories outside

STM32H7 dual-core MCU

UM2840 - Rev 1 page 83/132

UM2840

Hardware and software diagnostics

3.6.32

Quad-SPI interface (QUADSPI)

Table 125. QSPI_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

QSPI_SM_0

Periodical read-back of QUADSPI configuration registers

End user

This method must be applied to QUADSPI configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

Table 126. QSPI_SM_1

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

QSPI_SM_1

Protocol error signals including hardware CRC

ST

QUADSPI communication module embeds protocol error checks (like overrun, underrun, timeout etc.), conceived to detect communication-related abnormal conditions. These mechanisms are able anyway to detect a percentage of hardware random failures affecting the module itself.

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration (for example baud rate), please refer to functional documentation

Permanent and Transient Addressed fault model

Dependency on

Initialization

Periodicity

Device configuration None

Depends on implementation

Continuous

Test for the diagnostic

Multiple faults protection

N/A

QSPI_SM_2: Information redundancy techniques on messages

Recommendations and known limitations Enabling related interrupt generation on the detection of errors is highly recommended.

UM2840 - Rev 1 page 84/132

UM2840

Hardware and software diagnostics

Table 127. QSPI_SM_2

SM CODE

Description

Ownership

QSPI_SM_2

Information redundancy techniques on messages

Detailed implementation

End user

This method is implemented adding to data packets (not commands) transferred by QSPI interface a redundancy check (like a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet.

Consistency of data packet must be checked by the application software before consuming data

Depends on implementation Error reporting

Fault detection time

Addressed fault model

Depends on implementation

Permanent and Transient

Dependency on Device configuration None

Initialization Depends on implementation

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

To give an example on checksum encoding capability, using just a bit-by-bit addition is unappropriated.

This safety mechanism can overlap with information redundancy techniques implemented at system level to address failure of physical device connected to QSPI port

3.6.33

Serial audio interface (SAI)

Table 128. SAI_SM_0

SM CODE SAI_SM_0

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Periodical read-back of SAI configuration registers

End user

This method must be applied to SAI configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Test for the diagnostic

Multiple faults protection

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

UM2840 - Rev 1 page 85/132

UM2840

Hardware and software diagnostics

Table 129. SAI_SM_1

SM CODE

Description

Ownership

Detailed implementation

SAI_SM_1

SAI output loopback scheme

End user

This method uses a loopback scheme to detect permanent and transient faults on the output channel used for serial audio frame generation. It is implemented by connecting the second serial audio interface as input for primary output generation. The application software is able therefore to identify wrong or missing audio frame generation

Error reporting

Fault detection time

Depends on implementation

Depends on implementation

Addressed fault model Permanent and Transient

Dependency on Device configuration None

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Depends on implementation

Continuous/ On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Efficiency versus transient failures is linked to final application characteristics. We define as Tm the minimum duration of serial audio wrong signal permanence required to violate the related safety function(s). Efficiency is maximized when execution test frequency is higher than 1/Tm.

Method to be used when SAI interface safety-related use is “audio stream generation”

Table 130. SAI_SM_2

SM CODE SAI_SM_2

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

1oo2 scheme for SAI module

End user

This safety mechanism is implemented using the two SAI interfaces to decode/receive the same input stream audio. The application software checks the coherence between the received data

Depends on implementation

Depends on implementation

Permanent and Transient

None

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Recommendations and known limitations

The MCU performance overload and the implementation complexity associated to this method can be relevant.

Method to be used when SAI interface safety-related use is “audio stream receive”

3.6.34

Ethernet (ETH): media access control (MAC) with DMA controller

SM CODE

Description

Table 131. ETH_SM_0

ETH_SM_0

Periodical read-back of Ethernet configuration registers

UM2840 - Rev 1 page 86/132

UM2840

Hardware and software diagnostics

SM CODE ETH_SM_0

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

End user

This method must be applied to Ethernet configuration registers (including those relate to unused module features). Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

Table 132. ETH_SM_1

SM CODE

Description

Ownership

Detailed implementation

ETH_SM_1

Protocol error signals including hardware CRC

ST

Ethernet communication module embeds protocol error checks (like overrun, underrun, timeout, packet composition violation etc.) and CRC-packet checks as well, conceived to detect networkrelated abnormal conditions. These mechanisms are able anyway to detect a percentage of hardware random failures affecting the module itself.

Error flag raise and optional Interrupt Event generation Error reporting

Fault detection time

Addressed fault model

Dependency on

Initialization

Device configuration

Depends on peripheral configuration (e.g. baud rate), refer to functional documentation

Permanent and transient

None

Depends on implementation

Periodicity

Test for the diagnostic

Multiple faults protection

Continuous

N/A

ETH_SM_2 information redundancy techniques on messages, including end-to-end operation

Recommendations and known limitations Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Table 133. ETH_SM_2

ETH_SM_2

Information redundancy techniques on messages, including end-to-end operation

End user

This method aim to protect the communication between a peripheral and its external counterpart.

It is used in Ethernet local safety concept to address failures not detected by ETH_SM_1 and to increase its associated diagnostic coverage.

Refer to CAN_SM_2 description for detailed information.

Depends on implementation

Depends on implementation

Permanent and transient

UM2840 - Rev 1 page 87/132

UM2840

Hardware and software diagnostics

SM CODE ETH_SM_2

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

None

Depends on implementation

On demand

Not needed

Multiple faults protection CPUM7_SM_0, CPUM4_SM_0: periodical core self test software

Recommendations and known limitations

The implementation on the application software of complex Ethernet-based communication stacks

(like TCP/IP) is able to satisfy the requirements of this method.

Note:

3.6.35

The use of the DMA feature inside Ethernet module brings to adopt the same set of safety mechanism defined

for the system DMA (refer to Section 3.6.8 Direct memory access controllers (DMA, MDMA, BDMA and DMA request multiplexer (DMAMUX))

).

JPEG codec (JPEG)

Table 134. JPEG_SM_0

SM CODE

Description

Ownership

Detailed implementation

JPEG_SM_0

Periodical read-back of JPEG codec configuration registers.

End user

This method must be applied to JPEG codec configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0 Error reporting

Fault detection time

Addressed fault model

Dependency on

Initialization

Device configuration

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Periodicity

Test for the diagnostic

Multiple faults protection

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Table 135. JPEG_SM_1

JPEG_SM_1

Periodic test for JPEG encoding/decoding functions

End user

JPEG encoding/decoding functions performed by JPEG codec are tested by comparison, executing the functions over a set of reference images stored in the Flash memory and checking the correctness of output images. The method diagnostic coverage depends on the quantity and composition of image set used for the checks.

The comparison of output image with expected result can be executed bit-by-bit or even by faster methods like CRC-seed (computed via DMA transactions) checks.

Depends on implementation

Depends on implementation

Permanent

UM2840 - Rev 1 page 88/132

UM2840

Hardware and software diagnostics

SM CODE JPEG_SM_1

Dependency on Device configuration None

Initialization Depends on implementation

Periodicity

Test for the diagnostic

Periodic

N/A

Multiple faults protection

Recommendations and known limitations

CPUM7_SM_0, CPUM4_SM_0: periodical core self test software

If only one kind of function between encoding and decoding is used by application software, the method can be simplified restricting the test to the used function only.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Note:

3.6.36

Table 136. JPEG_SM_2

JPEG_SM_2

Application-level detection of failures affecting JPEG coding/encoding

End user

•

•

Several application-level methods can be used to detect failures affecting JPEG coding/encoding; being no possible to give detailed information for its implementation, only high level guidelines/hints are provided:

Permanent and transient failures: application software checks on expected output image characteristics (e.g. after the processing by image recognition algorithms)

– Transient faults: application software checks on images redundancy (in case of sequence coming from video stream) possibly discarding wrongly-processed frames.

This rationale could be also used to derate part of transient failure rate as “no effect”.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

Periodic/on demand

N/A

CPUM7_SM_0, CPUM4_SM_0: periodical core self test software

These methods are strictly application-dependent; therefore, their implementation and any related claims in terms of failure mitigations are End user ’s responsibility

The use of the DMA feature inside this module requires the adoption of the set of safety mechanism defined for the system DMA (refer to Direct memory access controllers (DMA, MDMA, BDMA)).

HDMI-CEC controller (CEC)

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Table 137. HDMI_SM_0

HDMI_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to CEC configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

UM2840 - Rev 1 page 89/132

UM2840

Hardware and software diagnostics

SM CODE

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

HDMI_SM_0

SM CODE

Description

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

Table 138. HDMI_SM_1

HDMI_SM_1

Protocol error signals

ST

CEC communication module embeds protocol error checks (such as additional parity bit check, overrun, frame error) conceived to detect network-related abnormal conditions. These mechanisms are able anyway to detect a marginal percentage of hardware random failures affecting the module itself.

Error signals connected to these checkers are normally handled in a standard communication software, so the overhead is reduced.

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration (for instance baud rate), refer to functional documentation.

Permanent and transient

None

Depends on implementation.

Continuous

Not needed

HDMI_SM_2: Information redundancy techniques on messages

Enabling related interrupt generation on the detection of errors is highly recommended.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Table 139. HDMI_SM_2

HDMI_SM_2

Information redundancy techniques on messages

End user

This method is implemented adding to data packets transferred by CEC a redundancy check

(such as CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust enough to guarantee at least 90% probability of detection for a single bit flip and multi-bits flip in the data packet.

Consistency of data packet must be checked by the application software before consuming data.

Depends on implementation

Depends on implementation

Permanent and transient

None

UM2840 - Rev 1 page 90/132

UM2840

Hardware and software diagnostics

SM CODE

Initialization

Periodicity

Test for the diagnostic

Multiple-fault protection

Recommendations and known limitations

HDMI_SM_2

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

It is assumed that the remote HDMI-CEC counterpart has an equivalent capability of performing the check described.

Transmission full redundancy (message repetition) should not be used because its detection capability is limited to a subset of communication unit failure modes.

To give an example on checksum encoding capability, using just a bit-by-bit addition is unappropriated.

3.6.37

Management data input/output (MDIOS)

Table 140. MDIO_SM_0

SM CODE

Description

Ownership

Detailed implementation

MDIO_SM_0

Periodical read-back of MDIO slave configuration registers.

End user

This method must be applied to MDIO slave configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0 Error reporting

Fault detection time

Addressed fault model

Dependency on

Initialization

Device configuration

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Periodicity

Test for the diagnostic

Multiple faults protection

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Table 141. MDIO_SM_1

MDIO_SM_1

Protocol error signals

ST

MDIO communication protocol is based on a packet handling concept, including preamble/ start/stop correct conditions checks. This mechanism, mainly implemented to manage on field communication disturbance, is able to achieve a relevant diagnostic coverage on several MDIO module failure modes

Error conditions are reported by flag bits in related registers, and interrupt generation

Depends on peripheral configuration and the type of violation detected, refer to functional documentation

Permanent and transient

None

Depends on implementation

UM2840 - Rev 1 page 91/132

UM2840

Hardware and software diagnostics

SM CODE MDIO_SM_1

Periodicity

Test for the diagnostic

Continuous

N/A

Multiple faults protection

Recommendations and known limitations -

MDIO_SM_0: periodical read-back of MDIO Host configuration registers.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

3.6.38

Table 142. MDIO_SM_2

MDIO_SM_2

Information redundancy techniques on MDIO registers contents, including register update awareness.

End user

Information provided by external parties by MDIO communication must be protected by redundancy schemes (encoded data values and possibly the definition of a “checksum” register).

•

•

•

The application software must be aware of any register value update executed by external parties, so it is needed the implementation of a “validate/unvalidate” mechanism to: report to external party that updated data have been consumed mark as “unvalidated” any data already consumed allow external party to inform application software that new data are available

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self test software

It is assumed that the external entity responsible to update/send data to application software by the

MDIO communication link is able to contribute to the MDIO failure mitigation, by detecting missing or incomplete data consumption.

SPDIF receiver interface (SPDIFRX)

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Table 143. SPDF_SM_0

SPDF_SM_0

Periodical read-back of SPDIF configuration registers

End user

This method must be applied to SPDIF configuration registers.

Detailed information on the implementation of this method can be found in section NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UM2840 - Rev 1 page 92/132

UM2840

Hardware and software diagnostics

SM CODE SPDF_SM_0

Test for the diagnostic

Multiple faults protection

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

Table 144. SPDF_SM_1

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

SPDF_SM_1

Protocol error signals

ST

IEC60598 S/PDIF data frame specification used in SPDIF interface embeds protocol error checks

(like overrun, underrun, bit timing violations, parity, etc.) conceived to detect transmission-related abnormal conditions. These mechanisms are able anyway to detect a marginal percentage of hardware random failures affecting the module itself.

Error flag raise and optional Interrupt Event generation

Depends on peripheral configuration, refer to functional documentation

Permanent and Transient

None

Initialization

Periodicity

Test for the diagnostic

Depends on implementation

Continuous

Not needed

Multiple faults protection SPDF_SM_0: periodical read-back of SPDIF configuration registers

Recommendations and known limitations Enabling related interrupt generation on the detection of errors is highly recommended.

Table 145. SPDF_SM_2

SM CODE SPDF_SM_2

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Information redundancy techniques on messages

End user

This method is implemented adding to data S/PDIF data stream some form of information redundancy, possibly including information repetition, to address failure modes affecting the decoding section of the module.

Depends on implementation

Depends on implementation

Permanent and transient

None

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self test software

Recommendations and known limitations

This method could be replaced by application-level alternative measures checking the correctness of the audio stream received. One given example could be represented by a set of plausibility checks executed after post-elaboration by voice recognition algorithms.

UM2840 - Rev 1 page 93/132

UM2840

Hardware and software diagnostics

3.6.39

True random number generator (RNG)

SM CODE

Description

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

Table 146. RNG_SM_0

RNG_SM_0

Periodical read-back of RNG configuration register RNG_CR

End user

This method must be applied to RNG configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

RNG module available only on specific part numbers

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

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

Table 147. RNG_SM_1

RNG_SM_1

RNG module entropy on-line tests

ST and End user

RNG module include an internal diagnostic for the analog source entropy that can be used to detect failures on the module itself. Furthermore, the required test on generated random number difference between the previous one (as required by FIPS PUB 140-2) can be exploited as well.

•

•

Implementation:

Check for RNG error conditions.

Check the difference between generated random number and the previous one.

CEIS, SEIS error bits in RNG status register (RNG_SR)

Application software error for FIPS PUB 140-2 test fail

Depends on implementation.

Permanent and transient

RNG module available only on specific part numbers

Depends on implementation.

Continuous

-

N/A

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

UM2840 - Rev 1 page 94/132

UM2840

Hardware and software diagnostics

3.6.40

Cryptographic processor (CRYP)

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 148. AES_SM_0

AES_SM_0

Periodical read-back of CRYP configuration registers

End user

This method must be applied to CRYP configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

CRYP module available only on specific part numbers

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 149. AES_SM_1

Encryption/decryption collateral detection

AES_SM_1

ST

Encryption and decryption operations performed by CRYP module are composed by several data manipulations and checks, with different level of complexity according to the selected chaining algorithm. A major part of the hardware random failures affecting CRYP module leads to algorithm violations/errors. Leading to decoding errors on the receiver side.

Several error conditions can happen, check functional documentation.

Depends on peripheral configuration

Permanent and Transient

CRYP module available only on specific part numbers

Depends on implementation.

-

Continuous

N/A

AES_SM_2: Information redundancy techniques on messages

SM CODE

Description

Ownership

Table 150. AES_SM_2

AES_SM_2

Information redundancy techniques on messages, including end-to-end protection.

End user

UM2840 - Rev 1 page 95/132

UM2840

Hardware and software diagnostics

SM CODE

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

AES_SM_2

This method aims to protect the communication between a peripheral and his external counterpart. It is used in AES local safety concept to address failures not detected by the encryption/decryption features.

Refer to CAN_SM_2 description for detailed information.

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

CRYP module available only on specific part numbers

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Refer to CAN_SM_2

Important note: it is assumed that the remote counterpart has an equivalent capability of performing the checks described.

Refer to CAN_SM_2 for further notice.

Note:

3.6.41

Hardware random failure consequences on potential security feature violations are not detailed in this manual.

HASH processor (HASH)

Table 151. HASH_SM_0

SM CODE

Description

Ownership

Detailed implementation

HASH_SM_0

Periodical read-back of HASH configuration registers

End user

This method must be applied to HASH configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Refer to NVIC_SM_0

HASH module available only on specific part numbers

Refer to NVIC_SM_0

Periodicity

Test for the diagnostic

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Multiple faults protection Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

SM CODE

Description

Ownership

Table 152. HASH_SM_1

HASH_SM_1

HASH processing collateral detection

ST

UM2840 - Rev 1 page 96/132

UM2840

Hardware and software diagnostics

SM CODE HASH_SM_1

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Message digest computation performed by HASH module is composed by several data manipulations and checks. A major part of the hardware random failures affecting HASH module will lead to algorithm violations/errors, and so to decoding errors on the receiver side

Several error condition can happens, check functional documentation

Depends on peripheral configuration

Permanent and transient

HASH module available only on specific part numbers

Depends on implementation

Periodicity

Test for the diagnostic

Continuous

N/A

Multiple faults protection

Recommendations and known limitations -

HASH_SM_0: periodical read-back of HASH configuration registers

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

Note:

3.6.42

Hardware random failures consequences on potential security features violations are not analyzed in this manual.

Digital filter for sigma delta modulators (DFSDM)

Table 153. DFS_SM_0

Description

Ownership

SM CODE

Detailed implementation

DFS_SM_0

Periodical read-back of DFSDM configuration registers

End user

This method must be applied to DFSDM configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Periodicity

Test for the diagnostic

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Multiple faults protection Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Table 154. DFS_SM_1

DFS_SM_1

Multiple acquisition by application software

End user

This method implements a timing information redundancy by executing multiple acquisitions on the same input signal. Multiple acquisition data are then combined by a filter algorithm to determine the signal correct value.

UM2840 - Rev 1 page 97/132

UM2840

Hardware and software diagnostics

SM CODE DFS_SM_1

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Depends on implementation

Depends on implementation

Transient

None

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Depends on implementation

Continuous

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Recommendations and known limitations

It is highly probable that this recommendation is satisfied by design by the End user application software. Usage of multiple acquisitions followed by average operations is a common technique in industrial applications where it is needed to survive with spurious EMI disturbs on sensor lines

Table 155. DFS_SM_2

SM CODE DFS_SM_2

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Range check by application software

End user

This method is implemented as described in ADC_SM_2: Range check by application software, refer to such safety mechanism for details.

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

Continuous

Test for the diagnostic

Multiple faults protection

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Recommendations and known limitations The implementation of this safety mechanism is strongly application-dependent

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Table 156. DFS_SM_3

DFS_SM_3

1oo2 scheme for DFSM inputs

End user

This safety mechanism is implemented using two different DFSM modules to acquire the same input signal. The application software checks the coherence between the two readings

Depends on implementation

Depends on implementation

Permanent and Transient

None

Depends on implementation

On demand

Not needed

UM2840 - Rev 1 page 98/132

UM2840

Hardware and software diagnostics

SM CODE DFS_SM_3

Multiple faults protection

Recommendations and known limitations

DSF_SM_0: Periodical read-back of DFSDM configuration registers

This method can be used in conjunction with DFS_SM_0 to achieve highest level of DFSM module diagnostic coverage (in alternative to DFS_SM1 and DFS_SM_2)

3.6.43

Digital camera interface (DCMI)

Table 157. DCMI_SM_0

SM CODE

Description

Ownership

Detailed implementation

DCMI_SM_0

Periodical read-back of DCMI configuration registers

End user

This method must be applied to DCMI configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0 Error reporting

Fault detection time

Addressed fault model

Dependency on

Initialization

Device configuration

Refer to NVIC_SM_0

Refer to NVIC_SM_0

DCMI interface is available only on selected part numbers

Refer to NVIC_SM_0

Periodicity

Test for the diagnostic

Multiple faults protection

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

Table 158. DCMI_SM_1

SM CODE

Description

Ownership

Detailed implementation

DCMI_SM_1

DCMI video input data synchronization

ST

According to the nature of video data stream received, DCMI module implements synchronization controls, from the simplest one (hardware synchronization) to the most complex (e.g. embedded data synchronization mode). DCMI internal failures leading to the incapability of correcting synchronizing the data stream can be therefore detected

Error reporting

Fault detection time

No explicit error signal/message generation is provided (*)

Depends on implementation

Addressed fault model Permanent

Dependency on Device configuration DCMI interface is available only on selected part numbers

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Depends on implementation

Continuous

N/A

DCMI_SM_0: Periodical read-back of DCMI configuration registers

(*) For its nature, the detection of an actual hardware failure by this safety mechanism can be confused with functional-related scenarios (e.g. camera device disconnected or powered-off). It is responsibility of the application software to discriminate, as far as it is technically possible, among different events

UM2840 - Rev 1 page 99/132

UM2840

Hardware and software diagnostics

3.6.44

LCD-TFT display controller (LTDC)

Table 159. LCD_SM_0

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

LCD_SM_0

Periodical read-back of LTDC configuration registers and buffer memory.

End user

This method must be applied to LTDC configuration registers and to the buffer memory as well.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

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

Table 160. LCD_SM_1

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

LCD_SM_1

LTDC acquisition by ADC channel

End user

Correct generation of LTDC driving signals is checked by ADC reading versus expected values

Depends on implementation

Depends on implementation

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Permanent

None

None

Periodic

Not needed

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Recommendations and known limitations

This method is conceived to mainly detect permanent failures affecting analog parts and therefore the execution on periodic way is acceptable. Diagnostic coverage achievable depends on the quantity of LTDC signals checked

Note: The above-described safety mechanism addresses the LTDC interface included in STM32 MCUs. Because actual capability of correct image generation on LTDC is not addressed by this safety mechanism, in case such feature is considered safety relevant the End user is warned to evaluate the adoption of adequate system-level measures.

UM2840 - Rev 1 page 100/132

UM2840

Hardware and software diagnostics

3.6.45

Comparator (COMP)

SM CODE

Description

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

Table 161. COMP_SM_0

COMP_SM_0

Periodical read-back of configuration registers

End user

This method must be applied to COMP configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

SM CODE

Description

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

Table 162. COMP_SM_1

COMP_SM_1

1oo2 scheme for comparator

End user

This safety mechanism is implemented using the two internal comparators to take the same decision. It requires that the comparator voting is handled accordingly.

Depends on implementation

Depends on implementation

Permanent and transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

This method is not compatible with “window” comparator feature.

SM CODE

Description

Ownership

Detailed implementation

Table 163. COMP_SM_2

COMP_SM_2

Plausibility check on inputs

End user

This method is used to redundantly acquire on dedicated ADC channels the analog inputs that are subjected to comparator function, and to periodically check the coherence of the comparator output on the measured values.

UM2840 - Rev 1 page 101/132

UM2840

Hardware and software diagnostics

SM CODE

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

COMP_SM_2

Depends on implementation

Depends on implementation

Permanent

None

Depends on implementation

Periodic

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

None

SM CODE

Description

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

Table 164. COMP_SM_3

COMP_SM_3

Multiple acquisition by application software

End user

This method requires that application software takes a decision not on the basis of a comparator single-shot transition, but after multiple events or after the permanence of comparator trigger conditions for a certain amount of time.

Depends on implementation

Depends on implementation

Transient

None

Depends on implementation

On demand

Not needed

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software

It is highly probable that this recommendation is satisfied by design on End user application

- multiple acquisition is a common technique in industrial applications facing electromagnetic interference on sensor lines.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Table 165. COMP_SM_4

COMP_SM_4

Comparator Lock mechanism

ST

This safety mechanism prevents configuration changes for comparator control and status registers; it addresses therefore systematic faults in the software application.

NA

NA

None (Fault avoidance)

None

Lock protection must be enabled through the COMPxLOCK bits of the COMP_CSR register.

Continuous

NA

UM2840 - Rev 1 page 102/132

UM2840

Hardware and software diagnostics

SM CODE

Multiple-fault protection

Recommendations and known limitations

COMP_SM_4

NA

This method does not addresses comparator configuration changes due to soft errors.

3.6.46

Operational amplifiers (OPAMP)

Table 166. AMP_SM_0

SM CODE AMP_SM_0

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Periodical read-back of OPAMP configuration registers

End user

This method must be applied to OPAMP configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Test for the diagnostic

Multiple-fault protection

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

Note: Because OPAMP modules are expected to be used in signal conditioning/amplification, their use in safetyrelated functions lead to an application level scenario. End user is therefore responsible for the mitigation of failure modes affecting the analog section of used OPAMP module(s).

UM2840 - Rev 1 page 103/132

UM2840

Hardware and software diagnostics

3.6.47

Delay block (DLYB)

Table 167. DLB_SM_0

Description

Ownership

SM CODE

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

DLB_SM_0

Periodical read-back of DLYB configuration registers

End user

This method must be applied to DLYB configuration registers.

Detailed information on the implementation of this method can be found in Section 3.6.7 EXTI controller

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Initialization

Periodicity

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Test for the diagnostic Refer to NVIC_SM_0

Multiple-fault protection Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

Note:

3.6.48

It is assumed that DLYB output, if used, feeds STM32H7 internal communication peripherals (like, for instance,

QUADSPI). It is also assumed that for the connected peripherals all prescript safety mechanisms (rated as ++ and +) are correctly implemented.

Voltage reference buffer (VREFBUF)

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

Table 168. VREF_SM_0

VREF_SM_0

Periodical read-back of VREFBUF system configuration registers

End user

This method must be applied to VREFBUF configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Refer to NVIC_SM_0

UM2840 - Rev 1 page 104/132

UM2840

Hardware and software diagnostics

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

Table 169. VREF_SM_1

VREF_SM_1

VREF cross-check by ADC reading

End user

This method is based on ADC acquisition for VREF generated signal, to crosscheck with the expected value.

Depends on implementation.

Depends on implementation.

Permanent

None

Depends on implementation.

On demand

N/A

CPUM7_SM_0, CPUM4_SM_0: Periodical core self test software

Overlaps with ADC_SM_3 are possible.

3.6.49

DSI Host (DSI)

Table 170. DSI_SM_0

SM CODE DSI_SM_0

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Periodical read-back of DSI Host configuration registers

End user

This method must be applied to DSI Host configuration registers.

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Test for the diagnostic

Multiple faults protection

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Recommendations and known limitations Refer to NVIC_SM_0

SM CODE

Description

Ownership

Detailed implementation

Table 171. DSI_SM_1

DSI_SM_1

Protocol error signals and information redundancy including hardware checksums

ST

DSI communication/command protocol is based on a packet handling concept, including (where applicable) ECC and checksum capabilities. This mechanism, mainly implemented to manage on field communication disturbance, is able to achieve a relevant diagnostic coverage on several DSI module failure modes

UM2840 - Rev 1 page 105/132

UM2840

Hardware and software diagnostics

SM CODE DSI_SM_1

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Error conditions are reported by flag bits in related registers

Depends on peripheral configuration and the type of violation detected, please refer to functional documentation

Permanent and transient

None

Depends on implementation

Continuous

Test for the diagnostic Not applicable

Multiple faults protection DSI_SM_0: Periodical read-back of DSI Host configuration registers

Recommendations and known limitations None

Note:

3.6.50

The above-described safety mechanisms addresses the DSI interface included in STM32 MCUs, including PHY.

Because actual capability of correct physical signal generation to drive the connected monitor is not addressed by these safety mechanisms, in case such feature is considered safety relevant the End user is warned to evaluate the adoption of adequate system-level measures.

Disable and periodic cross-check of unintentional activation of unused peripherals

This section reports the safety mechanism that addresses peripherals not used by the safety application, or not used at all.

SM CODE

Description

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

Table 172. FFI_SM_0

FFI_SM_0

Unused peripherals disable

End user

This method contributes to the reduction of the probability of cross-interferences caused by peripherals not used by the software application, in case a hardware failure causes an unintentional activation.

•

•

After the system boot, the application software must disable all unused peripherals with this procedure:

Enable reset flag on AHB and APB peripheral reset register

Disable clock distribution on AHB and APB peripheral clock enable register

NA

NA

NA

None

NA

Startup

Not needed

FFI_SM_1: Periodical read-back of interference avoidance registers

None

SM CODE

Description

Table 173. FFI_SM_1

FFI_SM_1

Periodical read-back of interference avoidance registers

UM2840 - Rev 1 page 106/132

UM2840

Hardware and software diagnostics

SM CODE

Ownership

Detailed implementation

Error reporting

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

FFI_SM_1

End user

•

•

This method contributes to the reduction of the probability of cross-interferences between peripherals that can potentially conflict on the same input/output pins, including for instance unused peripherals. This diagnostic measure must be applied to following registers: clock enable and disable registers alternate function programming registers

Detailed information on the implementation of this method can be found in

Section 3.6.7 EXTI controller

.

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

Refer to NVIC_SM_0

UM2840 - Rev 1 page 107/132

UM2840

Conditions of use

3.6.51

System

Table 174. DUAL_SM_0

SM CODE

Description

Ownership

Detailed implementation

DUAL_SM_0

Cross-check between two STM32 MCUs

End user

This method is implemented in the spirit of technique described in IEC 61508-7, A.3.5 “Reciprocal comparison by software”, which is rated in IEC 61508-2 Table A.4 as capable to achieve high level of diagnostic coverage.

•

•

•

•

•

The two processing units exchange data reciprocally, and a fail in the comparison is considered as a detection of a failure in one of the two unit. The guidelines for the implementation are the following:

Data exchanged include output results, intermediate results

(1)

and the results of each softwareimplemented safety mechanisms executed on periodical basis on both MCUs (for example

CPUM7_SM_0, CPUM4_SM_0)

Software routines devoted to data exchange/comparison must be logically separated from the software implementing the safety function(s).

Systematic capability of data exchange/comparison software must be equal or above the one of the software implementing the safety function(s).

Independency and lack of interference between the software implementing the data exchange/ comparison and the one implementing the safety function(s) must be proven.

Frequency of data exchange/comparison is imposed by the system PST (refer to (1) related timing

constraints for “periodic” safety mechanisms), except for output results which needs to be exchanged/ compared at the same rate they are potentially updated.

Depends on implementation

Permanent and transient

Fault detection time

Addressed fault model

Dependency on Device configuration

Initialization

Periodicity

Test for the diagnostic

Multiple faults protection

Recommendations and known limitations

None

Depends on implementation

Periodic

N/A

CPUM7_SM_0, CPUM4_SM_0: periodical core self-test software (individually executed on both processing units)

This method is usually rated as “optional” because it is not strictly needed in the framework of 1oo2 architecture described in

Section 3.2.4 Reference safety architectures - 1oo2 ; anyway, it is included here only for its use in

such an architecture.

This method can provide additional safety margin for systems needing further protection against fault accumulation.

Because this method could be a potential source of common cause failure between the two 1oo2 channels (in case of incorrect implementation), End user is recommended to carefully follow above the reported guidelines

(box “Detailed Implementation”).

1. It is defined here “intermediate result” the value of each variable able to directly influence the final individual channel output. To give some examples:

- if final output is a value resulting from some computation (for example a PWM rate), “intermediate results” are the values of each variable included in such computation.

- if final output if the result of a decision (for example GPIO value decided on the basis of the comparison between values), “intermediate results” are the values of each variable involved in such decision.

3.7

Conditions of use

The table below provides a summary of the safety concept recommendations reported in

Section 3.6 Hardware and software diagnostics

. The conditions of use to be applied to STM32H7 dual-core MCUs are reported in form of safety mechanism requirements. Exception is represented by some conditions of use introduced by FMEA analysis in order to correctly address specific failure modes. These conditions of use are reported at the end of the table presented in this section.

UM2840 - Rev 1 page 108/132

UM2840

Conditions of use

Rank column reports how related safety mechanism has been considered during the analysis, with following meaning:

• ++ = Highly recommended because considered in this Safety Manual as required to allow the implementation of safety functions up to SIL2 on a single Device. Missing implementation must be supported by adequate arguments under End user responsibility (refer to

Section 4.1.1

for guidance).

•

•

+ = Recommended as additional safety measure, but not considered in this Safety Manual for the computation of safety metrics. End users can skip the implementation in case it is in contradiction with functional requirements or overlapped by another mechanism marked as “++”.

o = optional, not needed or related to specific MCU configuration

The “X” marker in the “Perm” and “Trans” columns in the table below, indicates that the related safety mechanism is effective for such fault model.

The “X” marker in "Separation" column indicates that related recommendation is effective for the correct implementation of the separation concept described in

Section 3.2.5 The separation concept

.

STM32H7 dual-core function

Arm ® Cortex ® ‑ M7

CPU

Arm ® Cortex ® ‑ M4 CPU

CPUs-shared safety mechanisms

Embedded

Flash memory

Table 175. List of safety recommendations

Diagnostic Description Rank Perm Trans Separation

CPUM7_SM_0

Periodical software test addressing permanent faults in Arm ® Cortex ® ‑ M7 CPU core

CPUM7_SM_1 Control flow monitoring in application software

CPUM7_SM_2 Double computation in application software

++

++

++

CPUM7_SM_3 Arm ® Cortex ® ‑ M7 HardFault exceptions

CPUM7_SM_4 Stack hardening for application software

CPUM7_SM_7 MPU – Memory protection unit

CPUM7_SM_9

Periodical self ‑ test software for Arm ® caches

Cortex ® -M7

++

++

++

++

CPUM7_SM_10 ECC on Arm ® Cortex ® ‑ M7 L1 caches ++

MPUM7_SM_0 Periodical read ‑ back of MPU configuration registers ++

MPUM7_SM_1 MPU software tests ++

CPUM4_SM_0

Periodical software test addressing permanent faults in Arm ® Cortex ® ‑ M4 CPU core

CPUM4_SM_1 Control flow monitoring in application software

++

++

CPUM4_SM_3 Arm ® Cortex ® ‑ M7 HardFault exceptions

CPUM4_SM_4 Stack hardening for application software

++

++

CPUM4_SM_7 MPU – Memory protection unit ++

MPUM4_SM_0 Periodical read ‑ back of MPU configuration registers ++

MPUM4_SM_1 MPU software tests ++

CPU_SM_5

CPU_SM_6

External watchdog

Independent watchdog

CPU_SM_11 Cross-CPU safety information exchange

FLASH_SM_0

FLASH_SM_1

Periodical software test for Flash memory

Control flow monitoring in application software

FLASH_SM_2 Arm ® Cortex ® ‑ M7 HardFault exceptions

FLASH_SM_3 Option byte write protection

FLASH_SM_4 Static data encapsulation

+ +

++

++

++

(1)

++

++

++

+

X

X

-

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

-

X

X

X

-

X

-

X

X

X

X

X

-

X

X

-

-

X

-

-

-

X

X

-

X

X

X

X

X

-

X

X

-

-

X

X

-

X

-

X

X

-

X

X

X

X

X

-

-

-

-

-

X

X

X

UM2840 - Rev 1 page 109/132

UM2840

Conditions of use

STM32H7 dual-core function

Embedded

Flash memory

Embedded SRAM

System architecture

EXTI controller

DMA, MDMA, BDMA,

DMAMUX

DMA2D

HSEM

Single Wire Protocol

Master Interface

FDCAN

Diagnostic Description

FLASH_SM_6 Flash unused area filling code

FLASH_SM_7 ECC on Flash memory

FLASH_SM_8 Read/Write/Proprietary code protection

FLASH_SM_9

Periodic test by software for Flash memory address decoder

RAM_SM_0

RAM_SM_2

Periodical software test for SRAM

Stack hardening for application software

RAM_SM_3

RAM_SM_4

Information redundancy for system variables in application software

Control flow monitoring in application software

RAM_SM_5

RAM_SM_6

RAM_SM_7

Periodical integrity test for application software in

RAM

Read protection (RDP), Write protection (WRP)

ECC on SRAM

RAM_SM_8

DMA_SM_2

Periodic test by software for SRAM address decoder

BUS_SM_0

BUS_SM_1

Periodical software test for interconnections

Information redundancy in intra ‑ chip data exchanges

NVIC_SM_0 Periodical read ‑ back of configuration registers

NVIC_SM_1

Expected and unexpected interrupt check by application software

DMA_SM_0

DMA_SM_1

Periodical read ‑ back of configuration registers

Information redundancy on data packet transferred via DMA

Information redundancy by including sender or receiver identifier on data packet transferred via

DMA

DMA_SM_3

DMA_SM_4

DMA2D_SM_0

Periodical software test for DMA

DMA transaction awareness

Periodical read ‑ back of DMA2D configuration registers

DMA2D_SM_1 Periodical software test for DMA2D functions

DMA2D_SM_2 DMA processing and interrupt awareness

HSEM_SM_0

Periodical read ‑ back of HSEM configuration registers

HSEM_SM_1 Control flow monitoring for concurrent tasks

SWPMI_SM_0

Periodical read ‑ back of SWPMI configuration registers

SWPMI_SM_1

Protocol error signals and information redundancy including hardware CRC

SWPMI_SM_2 SWMPI loopback test

SWPMI_SM_3

CAN_SM_0

CAN_SM_1

Information redundancy techniques on messages to implement full end-to-end operation

Periodical read ‑ back of configuration registers

Protocol error signals

Rank Perm Trans Separation

+

++

+

++

+

+

++ o

(2) o (2)

+

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

+

++

++

++

-

X

-

X

X

X

X

X

X

-

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

-

X

-

-

-

X

X

X

X

X

-

-

-

X

X

X

X

X

X

-

X

X

-

X

X

X

X

X

-

X

X

X

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

UM2840 - Rev 1 page 110/132

UM2840

Conditions of use

STM32H7 dual-core function

FDCAN

USART, LPUART

I2C

SPI

USB OTG

ADC

DAC

Basic timers

(TIM6/7)

Advanced, general and low ‑ power timers

(TIM1/2/3/4/5/8/12,

TIM13/14/15/16/17, HRTIM and LPTIM)

CRC

GPIO

Diagnostic Description

CAN_SM_2

Information redundancy techniques on messages, including end-to-end operation

UART_SM_0 Periodical read ‑ back of configuration registers

UART_SM_1 Protocol error signals

UART_SM_2 Information redundancy techniques on messages

UART_SM_3

IIC_SM_0

IIC_SM_1

IIC_SM_2

IIC_SM_3

IIC_SM_4

SPI_SM_0

SPI_SM_1

SPI_SM_2

SPI_SM_3

SPI_SM_4

Information redundancy techniques on messages, including end-to-end operation

Periodical read ‑ back of configuration registers

Protocol error signals

Information redundancy techniques on messages

CRC packet ‑ level

Information redundancy techniques on messages, including end-to-end operation

Periodical read ‑ back of configuration registers

Protocol error signals

Information redundancy techniques on messages

CRC packet ‑ level

Information redundancy techniques on messages, including end-to-end operation

Periodical read ‑ back of configuration registers

Protocol error signals

Information redundancy techniques on messages

USB_SM_0

USB_SM_1

USB_SM_2

USB_SM_3

ADC_SM_0

ADC_SM_1

Information redundancy techniques on messages, including end-to-end operation

Periodical read ‑ back of configuration registers

Multiple acquisition by application software

Range check by application software ADC_SM_2

ADC_SM_3

ADC_SM_4

Periodical software test for ADC

1oo2 scheme for ADC inputs

DAC_SM_0

DAC_SM_1

Periodical read ‑ back of configuration registers

DAC output loopback on ADC channel

GTIM_SM_0 Periodical read ‑ back of configuration registers

GTIM_SM_1 1oo2 for counting timers

ATIM_SM_0

ATIM_SM_1

Periodical read ‑ back of configuration registers

1oo2 for counting timers

ATIM_SM_2

ATIM_SM_3

1oo2 for input capture timers

Loopback scheme for PWM outputs

ATIM_SM_4 Lock bit protection for timers

CRC_SM_0 CRC self ‑ coverage

GPIO_SM_0 Periodical read ‑ back of configuration registers

GPIO_SM_1 1oo2 for input GPIO lines

GPIO_SM_2 Loopback scheme for output GPIO lines

Rank Perm Trans Separation

++

++

++

++

+

+

++

++

++

+

++

++

++

++

+

++

++

++

+

++

++

++

++

+

++

++

++

++

++

++

++

++

+

++

++

++

++

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

-

X

X

X

X

X

X

-

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

-

X

X

X

X

X

X

X

X

X

-

X

X

X

X

X

X

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

UM2840 - Rev 1 page 111/132

UM2840

Conditions of use

STM32H7 dual-core function

GPIO

Diagnostic Description

RTC

Power control

Clock and Reset

IWDG / WWDG

Debug

System or peripheral control

SDMMC

Flexible static memory controller (FSMC)

QUADSPI

SAI

Ethernet (ETH): media access control (MAC) with

DMA controller

GPIO_SM_3 GPIO port configuration lock register

RTC_SM_0 Periodical read ‑ back of configuration registers

RTC_SM_1 Application check of running RTC

RTC_SM_2

RTC_SM_3

Information redundancy on backup registers

Application ‑ level measures to detect failures in timestamps or event capture

VSUP_SM_0 Periodical read ‑ back of configuration registers

VSUP_SM_1 Supply voltage monitoring

VSUP_SM_2 Independent Watchdog

VSUP_SM_3 Internal temperature sensor check

VSUP_SM_5 System-level power supply management

CLK_SM_0

CLK_SM_1

Periodical read ‑ back of configuration registers

CSS Clock Security System

CLK_SM_2

CLK_SM_3

WDG_SM_0

WDG_SM_1

Independent Watchdog

Internal clock cross ‑ measure

Periodical read ‑ back of configuration registers

Software test for watchdog at startup

DBG_SM_0 Independent watchdog

LOCK_SM_0 Lock mechanism for configuration options

SYSCFG_SM_0 Periodical read ‑ back of configuration registers

DIAG_SM_0

Periodical read ‑ back of hardware diagnostics configuration registers

SDIO_SM_0

Periodical read ‑ back of SDIO/SMMC configuration registers.

SDIO_SM_1

SDIO_SM_2

Protocol error signals including hardware CRC

Information redundancy techniques on messages

FSMC_SM_0 Control flow monitoring in application software

FSMC_SM_1

FSMC_SM_2

Information redundancy on external memory connected to FSMC

Periodical read ‑ back of FSMC configuration registers.

FSMC_SM_3 ECC engine on NAND interface in FSMC module

QSPI_SM_0

Periodical read ‑ back of QUADSPI configuration registers.

QSPI_SM_1 Protocol error signals including hardware CRC

QSPI_SM_2 Information redundancy techniques on messages

SAI_SM_0

SAI_SM_1

Periodical read ‑ back of SAI configuration registers.

SAI output loopback scheme

SAI_SM_2

ETH_SM_0

ETH_SM_1

1oo2 scheme for SAI module

Periodical read ‑ back of Ethernet configuration registers.

Protocol error signals including hardware CRC

Rank Perm Trans Separation

+

++

++

+ o

++

++

++

++

+

++

++

++

+

++ o

++

+

++

++

++

++

++

++ (3)

++

++ o

(3)

++

++

++

++

++

++

++

++

-

X

X

X

X

X

X

X

X

X

X

-

-

X

X

X

X

-

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

-

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

X

-

-

-

-

-

-

X

X

-

X

-

X

X

-

-

-

-

-

-

++

-

-

-

-

-

-

-

-

UM2840 - Rev 1 page 112/132

UM2840

Conditions of use

STM32H7 dual-core function

Ethernet (ETH): media access control (MAC) with

DMA controller

JPEG codec

HDMI CEC

MDIOS

SPDIFRX

RNG

CRYP

HASH

DFSDM

DCMI

LTDC

COMP

Diagnostic Description Rank Perm Trans Separation

ETH_SM_2

Information redundancy techniques on messages, including end-to-end operation

JPEG_SM_0

Periodical read ‑ back of JPEG codec configuration registers.

JPEG_SM_1 Periodic test for JPEG encoding/decoding functions

JPEG_SM_2

Application ‑ level detection of failures affecting

JPEG coding/encoding

HDMI_SM_0

Periodical read ‑ back of HDMI CEC configuration registers

HDMI_SM_1 Protocol error signals

HDMI_SM_2 Information redundancy techniques on messages

MDIO_SM_0

Periodical read ‑ back of MDIO slave configuration registers

MDIO_SM_1 Protocol error signals

MDIO_SM_2

SPDF_SM_0

Information redundancy techniques on MDIO registers contents, including register update awareness

Periodical read ‑ back of SPDIF configuration registers

SPDF_SM_1 Protocol error signals

SPDF_SM_2 Information redundancy techniques on messages

RNG_SM_0

Periodical read ‑ back of RNG configuration register

RNG_CR

RNG_SM_1

AES_SM_0

RNG module entropy on ‑ line tests

Periodical read ‑ back of CRYP configuration registers

AES_SM_1

AES_SM_2

HASH_SM_0

Encryption/decryption collateral detection

Information redundancy techniques on messages, including end-to-end operation

Periodical read ‑ back of HASH configuration registers

HASH_SM_1 HASH processing collateral detection

DFS_SM_0

Periodical read ‑ back of DFSDM configuration registers

DFS_SM_1

DFS_SM_2

Multiple acquisition by application software

Range check by application software

DFS_SM_3

DCMI_SM_0

1oo2 scheme for DFSM inputs

Periodical read ‑ back of DCMI configuration registers

DCMI_SM_1 DCMI video input data synchronization

LCD_SM_0

Periodical read ‑ back of LCD configuration registers and buffer memory.

LCD_SM_1 LCD acquisition by ADC channel

COMP_SM_0 Periodical read ‑ back of configuration registers

COMP_SM_1 1oo2 scheme for comparator

COMP_SM_2 Plausibility check on inputs

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

++

+

++

++

++

++

++

++

+

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

-

X

X

X

X

X

X

X

X

X

X

X

-

X

X

X

X

X

X

X

X

X

X

X

-

X

X

X

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

X

X

X

X

X

X

X

-

X

X

-

X

X

-

-

-

-

-

-

-

-

-

-

-

-

-

UM2840 - Rev 1 page 113/132

UM2840

Conditions of use

STM32H7 dual-core function

COMP

OPAMP

DLYB

VREFBUF

DSI

Part separation

(no interference)

Arm ® Cortex ® ‑ M7 and M4

CPU

Debug

Arm ® Cortex ® ‑ M7, M4 /

Supply system

STM32H7 Series peripherals

Flash subsystem

Flash subsystem

CPUs subsystems

CRS

Device

Embedded SRAM

Diagnostic Description

COMP_SM_3 Multiple acquisition by application software

COMP_SM_4 Comparator LOCK mechanism

AMP_SM_0

Periodical read ‑ back of OPAMP configuration registers

DLB_SM_0

Periodical read ‑ back of DLYB configuration registers

VREF_SM_0

Periodical read-back of VREFBUF system configuration registers

VREF_SM_1 VREF cross-check by ADC reading

DSI_SM_0

DSI_SM_1

FFI_SM_0

FFI_SM_1

CoU_1

CoU_2

CoU_3

Periodical read-back of DSI Host configuration registers

Protocol error signals and information redundancy including hardware checksums

Unused peripherals disable

Periodical read ‑ back of interference avoidance registers

The reset condition of Arm ® Cortex ® ‑ M7 and M4

CPUs must be compatible as valid safe state at system level

STM32H7 Series debug features must not be used in safety function(s) implementation

Low power mode state must not be used in safety function(s) implementation

CoU_4

CoU_5

CoU_6

CoU_7

CoU_8

CoU_9

End user must implement the required combination of safety mechanism/CoUs for each

STM32 peripherals used in safety function(s) implementation

During Flash memory bank mass erase and reprogramming there must not be safety function(s) executed by STM32H7 MCU.

On ‑ field application software live update by dual ‑ Flash system must include the execution of code/data integrity check by methods like

FLASH_SM_0

In case of multiple safety functions implementations, methods to guarantee their mutual independence must include MPU use.

CRS features must not be used in safety function(s) implementation

For each implemented safety mechanisms, related error/fault detection signal(s)/message(s) must be processed by the application software for the correct management of SS1 safe state. Related software routines must be considered as safety related in the framework of the overall policy for software systematic capability in the final system.

(4)

CoU_10

RAM space used by each Device CPU for safety function

(5)

implementation (including stacks space) must be kept separated, except the area specified by CoU_11. Allocation must be static.

Rank Perm Trans Separation

+

+

++

++

++

+

++

++

++

++

++

++

++

++

++

++

++

++

++

++

-

-

X

X

X

X

X

X

-

-

-

-

-

X

-

X

-

-

-

-

X

-

X

X

X

-

X

X

-

-

-

-

-

X

-

X

-

-

-

-

-

-

-

-

-

-

-

-

X

-

-

-

-

-

-

-

-

-

-

X

UM2840 - Rev 1 page 114/132

UM2840

Conditions of use

STM32H7 dual-core function

Diagnostic Description Rank

Embedded SRAM

Watchdogs

Part separation

(no interference)

1oo2 architecture

CoU_11

CoU_12

CoU_13

CoU_14

Data exchanges between the two CPUs of the

Device must use a dedicated shared memory space defined in SRAM.

Memory Protection Units (MPU) of each Device

CPU must be used to enforce the implementation of CoU_10, CoU_11.

The external watchdog must supervise the correct behavior of both Device CPUs. Communication schemes are ruled by CoU_14

CPUs communications with the external watchdog must be managed either:

1.

Both CPUs can communicate with the external watchdog. In this case the watchdog must be able to identify which CPU is sending the message, or

2.

Only one CPU drives the external watchdog and acts as supervisor for the other CPU.

In this case the first CPU must be able to request a reset in case the second CPU is unresponsive or reporting a failure detection.

CoU_15

CoU_16

CoU_17

In the Device, each of the two internal watchdogs

IWDG and WWDG must be statically allocated to only one CPU

(6)

.

External and internal watchdog management software routines (implementing requirements of

CoU_13,14,15) must be developed with software systematic capability (SC) not lower than the highest available on the system, and in any case at least equal to SC2

During system boot, a combination of the external watchdog and system-level measures must guarantee the overall safe state in case of missed correct application software start on each

CPU. Exit from this power-up safe state must be linked also to the successful execution (before the application software start) of following safety measures:

CPUM7_SM_0

MPUM7_SM_0

MPUM7_SM_1

CPUM4_SM_0

MPUM4_SM_0

MPUM4_SM_1

FLASH_SM_0

CoU_18

In 1oo2 architecture the PEv must keep the final system in safe state after the power-up until both

STM32H7 performed their exit from the power-up safe state ruled by CoU_17

DUAL_SM_0 Cross-check between two STM32 MCUs

++

++

++

++

++

++

++

++

Device o

1. Ranked "++" because considered as mitigation measure for Multiple-fault protection for FLASH_SM_7 (refer to related description).

2. Must be considered ranked as “++” if the application software is executed on RAM.

3. Can be considered ranked as “o” depending on the intended use of external memory connected to FSMC.

4. To provide an example, safety recommendation "CPUM7_SM_3 Arm ® Cortex ® ‑ M7 HardFault exceptions" cannot be considered correctly satisfied if related exception handler is not implemented in software.

Perm

-

-

X

-

-

-

-

-

X

Trans

-

-

X

-

-

-

-

-

X

Separation

X

X

X

X

X

X

X

X

-

UM2840 - Rev 1 page 115/132

UM2840

Conditions of use

5. It is reminded that any software-based safety mechanisms like CPUM7_SM_0, CPUM4_SM_0 must be considered “safety functions” and so they must comply to this CoU.

6. Therefore, trigger action on each internal watchdog must be possible for only one CPU, statically selected at software design time.

The above-described safety mechanism or conditions of use are conceived with different levels of abstraction depending on their nature: the more a safety mechanism is implemented as application-independent, the wider is its possible use on a large range of End user applications.

The safety analysis highlights two major partitions inside the MCU:

•

•

System-critical MCU modules. Every End user application is affected from a safety point of view by a failure on these modules. Because these modules are used by every End user application, related methods or safety mechanism are mainly conceived to be application-independent. For STM32H7 dualcore microcontroller system critical modules are: the two CPUs, Reset, Power, Clocks, Busmatrixs and

Interconnect, Flash and RAM memories (including their interfaces)

Peripheral modules. Such modules could be not used by the End user application, or they could be used for non-safety related tasks. Related safety methods are therefore implemented mainly at application level, as application software solutions or architectural solutions.

UM2840 - Rev 1 page 116/132

4

4.1

Note:

4.1.1

UM2840

Safety results

Safety results

This section reports the results of the safety analysis of the STM32H7 dual-core devices, according to IEC 61508 and to ST methodology flow, related to the hardware random and dependent failures.

Random hardware failure safety results

•

•

The analysis for random hardware failures of STM32H7 dual-core devices reported in this safety manual is executed according to STMicroelectronics methodology flow for safety analysis of semiconductor devices in compliance with IEC 61508. The accuracy of results obtained are guaranteed by three factors:

STMicroelectronics methodology flow strict adherence to IEC 61508 requirements and prescriptions the use, during the analysis, of detailed and reliable information on microcontroller design

• the use of state-of-the-art fault injection methods and tools for safety metrics verification

The Device safety analysis explored the overall and exhaustive list of Device failure modes, to individuate for each of them an adequate mitigation measure (safety mechanism). The overall list of Device failure modes is maintained in the related FMEA document, provided on demand by local STMicroelectronics sales office.

In summary, with the adoption of the safety mechanisms and conditions of use reported in

Section 3.7 Conditions of use , it is possible to achieve the integrity levels summarized in the following table.

Table 176. Overall achievable safety integrity levels

Number of

Devices used

Safety architecture

Target Safety analysis result

1

2

1oo1/1oo1D

1oo2

SIL 2 LD Achievable

SIL 2 HD / CM Achievable with potential performance impact

(1)

SIL 3 LD Achievable

SIL 3 HD / CM Achievable with potential performance impact

1. Note that the potential performance impact related to some above-reported target achievements is mainly related to the need of execution of periodical software-based diagnostics (refer to safety mechanism description for details). The impact

is therefore strictly related to how much “aggressive” the system level PST is (see Section 3.3.1 Safety requirement assumptions

).

•

•

The resulting relative safety metrics ( diagnostic coverage (DC) and safe failure fraction (SFF)

) and absolute

safety metrics ( probability of failure per hour (PFH)

,

probability of dangerous failure on demand (PFD)

) are not reported in this section but in the

failure mode effect diagnostic analysis (FMEDA) snapshot, due to:

• a large number of different STM32H7 dual-core parts, a possibility to declare non-safety-relevant unused peripherals, and a possibility to enable or not the different available safety mechanisms.

The FMEDA snapshot is a static document reporting the safety metrics computed at different detail levels (at microcontroller level and for microcontroller basic functions) for a given combination of safety mechanisms and for a given part number. If FMEDA computation sheet is needed, early contact the local STMicroelectronics sales representative, in order to receive information on expected delivery dates for specific Device target part number.

Safety metrics computations are restricted to STM32H7 dual-core boundary, hence they do not include the

WDTe, PEv, and VMONe processes described in Section 3.3.1 Safety requirement assumptions

).

Safety analysis result customization

The safety analysis executed for STM32H7 dual-core devices documented in this safety manual considers all microcontroller modules to be safety-related, thus able to interfere with the safety function, with no exclusion. This is in line with the conservative approach to be followed during the analysis of a general-purpose microcontroller, in order to be agnostic versus the final application. This means that no microcontroller module has been declared safe as per IEC 61508-4, 3.6.8. Therefore, all microcontroller modules are included in SFF computations.

UM2840 - Rev 1 page 117/132

Note:

4.1.2

UM2840

Random hardware failure safety results

•

•

In actual End user applications, not all the STM32H7 dual-core parts or modules implement a safety function.

That happens if:

The part is not used at all (disabled), or

The part implements functions that are not safety-related (for example, a GPIO line driving a power-on signaling light on an electronic board).

Implementation of non-safety-related functions is in principle forbidden by the assumed safety requirement

ASR6 (see

Section 3.3.1 Safety requirement assumptions

), hence under End user's entire responsibility. As any other derogation from safety requirements included in this manual, it is End user's responsibility to provide consistent rationales and evidences that the function does not bring additional risks, by following the procedure described in this section. Therefore, it is strongly recommended to reserve such derogation to very simple functions (as the one provided in the example).

•

•

Implementing safety mechanisms on such parts would be a useless effort for End user . The safety analysis results can therefore be customized.

End user can define a STM32H7 dual-core part as non-safety-related based on:

•

Collecting rationales and evidences that the part does not contribute to safety function.

Collecting rationales and evidences that the part does not interfere with the safety function during normal operation, due to final system design decisions. Mitigation of unused modules is exhaustively addressed in

Section 4.1.2 General requirements for freedom from interferences (FFI) .

Fulfilling the general condition for the mitigation of intraMCU interferences (see

Section 4.1.2 General requirements for freedom from interferences (FFI) ).

For a non-safety-related part, End user is allowed to:

• Exclude the part from computing metrics to report in FMEDA , and

•

Not implement safety mechanisms as listed in Table 175. List of safety recommendations

.

With regard to SFF computation, this section complies with the no part / no effect definition as per IEC 61508 ‑ 4,

3.6.13 / 3.6.14.

General requirements for freedom from interferences (FFI)

A dedicated analysis has highlighted a list of general requirements to be followed in order to mitigate potential interferences between Device internal module in case of internal failures (freedom from interferences, FFI). These precautions are integral part of the Device safety concept and they can play a relevant role when multiple microcontroller modules are declared as non-safety-related by End user

as per Section 4.1.1 Safety analysis result customization

.

End user must implement the safety mechanisms listed in

Table 177 (implementation details in

Section 3.6 Hardware and software diagnostics

) regardless any evaluation of their contribution to safety metrics.

Table 177. List of general requirements for FFI

Diagnostic

FFI_SM_0

FFI_SM_1

Unused peripheral disable

Description

Periodical read-back of interference avoidance registers

BUS_SM_0 Periodical software test for interconnections

NVIC_SM_0 Periodical read-back of configuration registers

NVIC_SM_1 Expected and unexpected interrupt check by application software

DMA_SM_0 Periodical read-back of configuration registers

DMA_SM_2 Information redundancy including sender or receiver identifier on data packet transferred via DMA

(1)

DMA_SM_4 DMA transactions awareness

(1)

GPIO_SM_0 Periodical read-back of configuration registers

1. To be implemented only if DMA is actually used

UM2840 - Rev 1 page 118/132

4.1.3

4.2

4.2.1

4.2.2

UM2840

Analysis of dependent failures

Notes on multiple-fault scenario

According to the requirements of IEC61508, the safety analysis for STM32H7 dual-core devices considered multiple-fault scenarios. Furthermore, following the spirit of ISO26262 (the reference and state-of-the-art standard norm for integrated circuit safety analysis), the analysis investigated possible causes preventing the implemented safety mechanisms from being effective, in order to determine appropriate counter-measures. In the Multiple-fault protection field, the tables in

Section 3.6 Hardware and software diagnostics

report the safety mechanisms required to properly manage a multiple-fault scenario, including mitigation measures against failures making safety mechanisms ineffective. It is strongly recommended that the safety concept includes such mitigation measures, and in particular for systems operating during long periods, as they tend to accumulate errors. Indeed, fault accumulation issue has been taken into account during STM32H7 dual-core devices safety analysis.

Another potential source of multiple error condition is the accumulation of permanent failures during power-off periods. Indeed, if the end system is not powered, no safety mechanism are active and so able to early detect the insurgence of such failures. To mitigate this potential issue, it is strongly recommended to execute all periodic safety mechanism at each system power-up; this measure guarantees a fresh system start with a fault-free hardware. This recommendation is given for periodic safety mechanisms rated as "++" (highly recommended) in the Device safety concept, and mainly for the most relevant ones in term of failure distribution: CPUM7_SM_0,

CPUM4_SM_0, FLASH_SM_0, RAM_SM_0. This startup execution is strongly recommended regardless the safety functions mode of operations and/or the value of PST.

Analysis of dependent failures

The analysis of dependent failures is important for microcontroller and microprocessor devices. The main subclasses of dependent failures are CCFs . Their analysis is ruled by IEC 61508-2 annex E, which lists the design requirements to be verified to allow the use of on-chip redundancy for integrated circuits with one common semiconductor substrate.

As there is no on-chip redundancy on STM32H7 dual-core devices, the CCF quantification through the βIC computation method - as required by Annex E.1, item i - is not required. Note that, in the case of 1oo2 safety architecture implementation, End user is required to evaluate the β and βD parameters (used in PFH computation) that reflect the common cause factors between the two channels.

The Device architecture and structures can be potential sources of dependent failures. These are analyzed in the following sections. The referred safety mechanisms are described in

Section 3.6 Hardware and software diagnostics

.

Power supply

•

•

Power supply is a potential source of dependent failures, because any alteration can simultaneously affect many modules, leading to not-independent failures. The following safety mechanisms address and mitigate those dependent failures:

VSUP_SM_1: detection of abnormal value of supply voltage;

VSUP_SM_2: the external watchdog is different from the digital core of the MCU , and this diversity helps to mitigate dependent failures related to the main supply alterations. As reported in VSUP_SM_2 description, separate power supply for IWDG or/and the adoption of an external watchdog (CPU_SM_5) increase such diversity.

The adoption of such safety mechanisms is therefore highly recommended despite their minor contribution to the safety metrics to reach the required safety integrity level. Refer to

Section 3.6.23 Power controller (PWR)

for the detailed safety mechanism descriptions.

•

Clock

System clocks are a potential source of dependent failures, because alterations in the clock characteristics

(frequency, jitter) can affect many parts, leading to not-independent failures. The following safety mechanisms address and mitigate such dependent failures:

• CLK_SM_1: the clock security system is able to detect hard alterations (stop) of system clock and activate the adequate recovery actions.

CLK_SM_2: the external watchdog has a dedicated clock source. The frequency alteration of the system clock leads to the watchdog window violations by the triggering routine on Application software , leading to the MCU reset by watchdog.

UM2840 - Rev 1 page 119/132

4.2.3

Note:

4.2.4

UM2840

Analysis of dependent failures

The adoption of such safety mechanism is therefore highly recommended despite their minor contribution to the safety metrics to reach the required safety integrity level. Refer to

Section 3.6.24 Reset and clock controller

(RCC)

for detailed safety mechanisms description.

•

DMA

•

•

The DMA function can be involved in data transfers operated by most of the peripherals. Failures of DMA can interfere with the behavior of the system peripherals or Application software , leading to dependent failures. The adoption of the following safety mechanisms is therefore highly recommended (refer to

Section 3.6.8 Direct memory access controllers (DMA, MDMA, BDMA and DMA request multiplexer (DMAMUX)) for description):

DMA_SM_0

DMA_SM_1

DMA_SM_2

Only DMA_SM_0 must be implemented if DMA is not used for data transfer.

Internal temperature

The abnormal increase of the internal temperature is a potential source of dependent failures, as it can affect many MCU

parts. The following safety mechanism mitigates this potential effect (refer to Section 3.6.23 Power controller (PWR) for description):

VSUP_SM_3: the internal temperature read and check allows the user to quickly detect potential risky conditions before they lead to a series of internal failures.

UM2840 - Rev 1 page 120/132

5

UM2840

List of evidences

List of evidences

A safety case database stores all the information related to the safety analysis performed to derive the results and conclusions reported in this safety manual.

The safety case database is composed of the following:

• safety case with the full list of all safety-analysis-related documents

•

•

•

STMicroelectronics' internal FMEDA tool database for the computation of safety metrics, including estimated and measured values safety report, a document that describes in detail the safety analysis executed on STM32H7 dual-core devices and the clause-by-clause compliance to IEC 61508

STMicroelectronics' internal fault injection campaign database including tool configuration and settings, fault injection logs and results

As these materials contain STMicroelectronics' confidential information, they are only available for the purpose of audit and inspection by authorized bodies, without being published, which conforms to Note 2 of IEC 61508-2,

7.4.9.7.

UM2840 - Rev 1 page 121/132

Revision history

Date

05-Jul-2021

Table 178. Document revision history

Version

1

Changes

Initial release.

UM2840

UM2840 - Rev 1 page 122/132

UM2840

Glossary

Glossary

Application software within the software executed by

Device , the part that ensures functionality of End user 's application and integrates safety functions

CCF common cause failure

CM continuous mode

Compliant item any item subject to claim with respect to the clauses of IEC 61508 series of standards

COTS commercial off-the-shelf

CoU conditions of use

CPU central processing unit

CRC cyclic redundancy check

DC diagnostic coverage

Device depending on context, any single or all of the

STM32H7 dual-core silicon products

DMA direct memory access

DTI diagnostic test interval

ECM engine control module

ECU electronic control unit

End user individual person or company who integrates Device in their application, such as an electronic control board

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

MPU memory protection unit

MTBF mean time between failures

MTTFd mean time to dangerous failure

PDS(SR) safety-related power drive system

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

SILCL safety integrity level claim limit

SRCF safety-related control function

SRECS safety-related electrical control systems

SRP/CS safety-related parts of machinery control systems

UM2840 - Rev 1 page 123/132

UM2840

Contents

Contents

1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

1.1

Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2

Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3

Reference documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Device development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

3 Reference safety architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

3.1

Safety architecture introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2

Compliant item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.1

3.2.2

3.2.3

3.2.4

Definition of Compliant item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Safety functions performed by Compliant item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Reference safety architectures - 1oo1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Reference safety architectures - 1oo2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.5

The separation concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3

Safety analysis assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1

Safety requirement assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4

Electrical specifications and environment limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5

Systematic safety integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.6

Hardware and software diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6.1

3.6.2

3.6.3

3.6.4

3.6.5

Arm ® Cortex ® -M7 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Arm ® Cortex ® -M4 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

CPUs-shared safety mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Embedded Flash memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Embedded SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.6

3.6.7

3.6.8

System bus architecture/peripherals interconnect matrix . . . . . . . . . . . . . . . . . . . . . . . . . 38

EXTI controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Direct memory access controllers (DMA, MDMA, BDMA and DMA request multiplexer

(DMAMUX)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chrom-Art Accelerator controller (DMA2D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.6.9

3.6.10

Hardware semaphore (HSEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.6.11

Single Wire Protocol Master Interface (SWPMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.6.12

FD controller area network (FDCAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

UM2840 - Rev 1 page 124/132

UM2840 - Rev 1

UM2840

Contents

3.6.13

Universal synchronous/asynchronous receiver/transmitter (USART 1/2/3/4/5/6/7/8,

LPUART1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.6.14

Inter-integrated circuit (I2C1/2/3/4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.6.15

Serial peripheral interface (SPI) 1/2/3/4/5/6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.6.16

USB on-the-go high-speed (OTG_HS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.6.17

Analog-to-digital converters (ADC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.6.18

Digital-to-analog converter (DAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.6.19

Basic timers TIM 6/7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.6.20

Advanced, general, high resolution and low ‑ power timers

(TIM1/2/3/4/5/8/12/13/14/15/16/17, HRTIM and LPTIM) . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.6.21

General-purpose input/output (GPIO) - Port A/B/C/D/E/F/G/H/I/J/K . . . . . . . . . . . . . . . . . 69

3.6.22

Real-time clock module (RTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.6.23

Power controller (PWR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.6.24

Reset and clock controller (RCC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.6.25

Independent watchdog (IWDG), system window watchdog (WWDG) . . . . . . . . . . . . . . . . 77

3.6.26

Clock recovery system (CRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.6.27

Debug support (DBG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.6.28

Cyclic redundancy-check module (CRC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.6.29

System configuration controller (SYSCFG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.6.30

SD/SDIO/MMC card host interface (SDMMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.6.31

Flexible static memory controller (FSMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.6.32

Quad-SPI interface (QUADSPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.6.33

Serial audio interface (SAI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.6.34

Ethernet (ETH): media access control (MAC) with DMA controller . . . . . . . . . . . . . . . . . . 86

3.6.35

JPEG codec (JPEG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.6.36

HDMI-CEC controller (CEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.6.37

Management data input/output (MDIOS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.6.38

SPDIF receiver interface (SPDIFRX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.6.39

True random number generator (RNG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.6.40

Cryptographic processor (CRYP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.6.41

HASH processor (HASH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.6.42

Digital filter for sigma delta modulators (DFSDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.6.43

Digital camera interface (DCMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

page 125/132

UM2840

Contents

3.6.44

LCD-TFT display controller (LTDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.6.45

Comparator (COMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.6.46

Operational amplifiers (OPAMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3.6.47

Delay block (DLYB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.6.48

Voltage reference buffer (VREFBUF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.6.49

DSI Host (DSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.6.50

Disable and periodic cross-check of unintentional activation of unused peripherals . . . . 106

3.6.51

System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

3.7

Conditions of use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108

4 Safety results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.1

Random hardware failure safety results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.1.1

4.1.2

4.1.3

Safety analysis result customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

General requirements for freedom from interferences (FFI) . . . . . . . . . . . . . . . . . . . . . . 118

Notes on multiple-fault scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.2

Analysis of dependent failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.2.1

4.2.2

4.2.3

4.2.4

Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Internal temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

5 List of evidences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

UM2840 - Rev 1 page 126/132

UM2840

List of tables

List of tables

Table 1. Document sections versus IEC 61508-2 Annex D safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Table 2. SS1 and SS2 safe state details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Table 3. CPUM7_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Table 4. CPUM7_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Table 5. CPUM7_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Table 6. CPUM7_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Table 7. CPUM7_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Table 8. CPUM7_SM_7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Table 9. CPUM7_SM_9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Table 10. CPUM7_SM_10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Table 11. MPUM7_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Table 12. MPUM7_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Table 13. CPUM4_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Table 14. CPUM4_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Table 15. CPUM4_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Table 16. CPUM4_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Table 17. CPUM4_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Table 18. CPUM4_SM_7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Table 19. MPUM4_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Table 20. MPUM4_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Table 21. CPU_SM_5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Table 22. CPU_SM_6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Table 23. CPU_SM_11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Table 24. FLASH_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Table 25. FLASH_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Table 26. FLASH_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Table 27. FLASH_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Table 28. FLASH_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Table 29. FLASH_SM_6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Table 30. FLASH_SM_7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Table 31. FLASH_SM_8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Table 32. FLASH_SM_9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Table 33. RAM_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Table 34. RAM_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Table 35. RAM_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 36. RAM_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 37. RAM_SM_5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Table 38. RAM_SM_6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Table 39. RAM_SM_7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Table 40. RAM_SM_8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Table 41. BUS_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Table 42. BUS_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Table 43. LOCK_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Table 44. NVIC_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Table 45. NVIC_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Table 46. DMA_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Table 47. DMA_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Table 48. DMA_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Table 49. DMA_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Table 50. DMA_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Table 51. DMA2D_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Table 52. DMA2D_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

UM2840 - Rev 1 page 127/132

UM2840

List of tables

Table 53. DMA2D_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Table 54. HSEM_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Table 55. HSEM_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Table 56. SWPMI_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Table 57. SWPMI_SM_1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Table 58. SWPMI_SM_2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Table 59. SWPMI_SM_3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Table 60. CAN_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Table 61. CAN_SM_1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Table 62. CAN_SM_2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Table 63. UART_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Table 64. UART_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Table 65. UART_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Table 66. UART_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Table 67. IIC_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Table 68. IIC_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Table 69. IIC_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Table 70. IIC_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Table 71. IIC_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Table 72. SPI_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Table 73. SPI_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Table 74. SPI_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 75. SPI_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 76. SPI_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Table 77. USB_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Table 78. USB_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Table 79. USB_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Table 80. USB_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Table 81. ADC_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Table 82. ADC_SM_1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Table 83. ADC_SM_2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Table 84. ADC_SM_3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Table 85. ADC_SM_4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Table 86. DAC_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Table 87. DAC_SM_1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Table 88. GTIM_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Table 89. GTIM_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Table 90. ATIM_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Table 91. ATIM_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Table 92. ATIM_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Table 93. ATIM_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Table 94. ATIM_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Table 95. GPIO_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Table 96. GPIO_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Table 97. GPIO_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Table 98. GPIO_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Table 99. RTC_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Table 100. RTC_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Table 101. RTC_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table 102. RTC_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table 103. VSUP_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Table 104. VSUP_SM_1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Table 105. VSUP_SM_2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Table 106. VSUP_SM_3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

UM2840 - Rev 1 page 128/132

UM2840

List of tables

Table 107. VSUP_SM_5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Table 108. CLK_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Table 109. CLK_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Table 110. CLK_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Table 111. CLK_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Table 112. WDG_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Table 113. WDG_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Table 114. DBG_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Table 115. CRC_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Table 116. SYSCFG_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Table 117. DIAG_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Table 118. SDIO_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Table 119. SDIO_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Table 120. SDIO_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Table 121. FSMC_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Table 122. FSMC_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Table 123. FSMC_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Table 124. FSMC_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Table 125. QSPI_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Table 126. QSPI_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Table 127. QSPI_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Table 128. SAI_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Table 129. SAI_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Table 130. SAI_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Table 131. ETH_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Table 132. ETH_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Table 133. ETH_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Table 134. JPEG_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table 135. JPEG_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table 136. JPEG_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Table 137. HDMI_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Table 138. HDMI_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table 139. HDMI_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table 140. MDIO_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Table 141. MDIO_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Table 142. MDIO_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Table 143. SPDF_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Table 144. SPDF_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Table 145. SPDF_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Table 146. RNG_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Table 147. RNG_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Table 148. AES_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Table 149. AES_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Table 150. AES_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Table 151. HASH_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Table 152. HASH_SM_1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Table 153. DFS_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Table 154. DFS_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Table 155. DFS_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Table 156. DFS_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Table 157. DCMI_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Table 158. DCMI_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Table 159. LCD_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Table 160. LCD_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

UM2840 - Rev 1 page 129/132

UM2840

List of tables

Table 161. COMP_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Table 162. COMP_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Table 163. COMP_SM_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Table 164. COMP_SM_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Table 165. COMP_SM_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Table 166. AMP_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Table 167. DLB_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Table 168. VREF_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Table 169. VREF_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Table 170. DSI_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Table 171. DSI_SM_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Table 172. FFI_SM_0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Table 173. FFI_SM_1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Table 174. DUAL_SM_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Table 175. List of safety recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Table 176. Overall achievable safety integrity levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

Table 177. List of general requirements for FFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

Table 178. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

UM2840 - Rev 1 page 130/132

UM2840

List of figures

List of figures

Figure 1. STMicroelectronics product development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Figure 2. STM32 as Compliant item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Figure 3. Individual and collaborative schemes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 4. 1oo1 reference architecture - individual scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 5. 1oo1 reference architecture - collaborative scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 6. 1oo2 reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 7. Allocation and target for STM32 PST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

UM2840 - Rev 1 page 131/132

UM2840

IMPORTANT NOTICE – PLEASE READ CAREFULLY

STMicroelectronics International NV and its affiliates (“ST”) reserve the right to make changes corrections, enhancements, modifications, and improvements to

ST products and/or to this document any time without notice.

This document is provided solely for the purpose of obtaining general information relating to an ST product. Accordingly, you hereby agree to make use of this document solely for the purpose of obtaining general information relating to the ST product. You further acknowledge and agree that this document may not be used in or in connection with any legal or administrative proceeding in any court, arbitration, agency, commission or other tribunal or in connection with any action, cause of action, litigation, claim, allegation, demand or dispute of any kind. You further acknowledge and agree that this document shall not be construed as an admission, acknowledgment or evidence of any kind, including, without limitation, as to the liability, fault or responsibility whatsoever of

ST or any of its affiliates, or as to the accuracy or validity of the information contained herein, or concerning any alleged product issue, failure, or defect. ST does not promise that this document is accurate or error free and specifically disclaims all warranties, express or implied, as to the accuracy of the information contained herein. Accordingly, you agree that in no event will ST or its affiliates be liable to you for any direct, indirect, consequential, exemplary, incidental, punitive, or other damages, including lost profits, arising from or relating to your reliance upon or use of this document.

Purchasers should obtain the latest relevant information on ST products before placing orders. ST products are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgment, including, without limitation, the warranty provisions thereunder.

In that respect please note that ST products are not designed for use in some specific applications or environments described in above mentioned terms and conditions.

Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of purchasers’ products.

Information furnished is believed to be accurate and reliable. However, ST assumes no responsibility for the consequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. No license, express or implied, to any intellectual property right is granted by ST herein.

Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.

ST and the ST logo are trademarks of ST. For additional information about ST trademarks, please refer to www.st.com/trademarks . All other product or service names are the property of their respective owners.

Information in this document supersedes and replaces information previously supplied in any prior versions of this document.

© 2021 STMicroelectronics – All rights reserved

UM2840 - Rev 1 page 132/132