ST STM32L4 Series Bedienungsanleitung

Introduction

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

STM32L4 and STM32L4+ Series microcontroller devices, 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, and it provides information relative to other functional safety standards.

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

package.

STM32L4 and STM32L4+ Series safety manual

UM2305

User manual

UM2305 - Rev 10 - June 2021

For further information contact your local STMicroelectronics sales office.

www.st.com

1About this document

1.1 Purpose and scope

This document describes how to use Arm® Cortex®‑M4 -based STM32L4 and STM32L4+ Series 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: 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 other functional safety standards considered in this manual are:

• ISO 13849-1:2015, ISO13849-2:2012

• IEC 62061:2005+AMD1:2012+AMD2:2015

• IEC 61800-5-2:2016

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

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

Safety requirement Section number

D2.1 a) a functional specification of the functions capable of being performed 3

D2.1 b) identification of the hardware and/or software configuration of the Compliant item 3.2

D2.1 c) constraints on the use of Compliant item or assumptions on which analysis of the behavior or

failure rates of the item are based 3.2

D2.2 a) the failure modes of Compliant item due to random hardware failures, that result in a failure of

the function and that are not detected by diagnostics internal to Compliant item;

3.7

D2.2 b) for every failure mode in a), an estimated failure rate;

D2.2 c) the failure modes of Compliant item due to random hardware failures, that result in a failure of

the function and that are detected by diagnostics internal to Compliant item;

D2.2 d) the failure modes of the diagnostics, internal to Compliant item due to random hardware failures,

that result in a failure of the diagnostics to detect failures of the function;

D2.2 e) for every failure mode in c) and d), the estimated failure rate;

D2.2 f) for every failure mode in c) that is detected by diagnostics internal to Compliant item, the

diagnostic test interval; 3.2.2

D2.2 g) for every failure mode in c) the outputs of Compliant item initiated by the internal diagnostics; 3.6

D2.2 h) any periodic proof test and/or maintenance requirements;

3.7

D2.2 i) for those failure modes, in respect of a specified function, that are capable of being detected by

external diagnostics, sufficient information must be provided to facilitate the development of an external

diagnostics capability.

D2.2 j) the hardware fault tolerance;

D2.2 k) the classification as type A or type B of that part of Compliant item that provides the function (see

7.4.4.1.2 and 7.4.4.1.3);

UM2305

About this document

UM2305 - Rev 10 page 2/110

1.3 Reference documents

[1] AN5112: Results of FMEA on STM32L4 and STM32L4+ Series microcontrollers.

[2] AN5111: FMEDA snapshots for STM32L4 and STM32L4+ Series microcontrollers.

UM2305

Reference documents

UM2305 - Rev 10 page 3/110

2Device 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

·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

1 Conception 3 Qualification

2 Design and

validation

UM2305

Device development process

UM2305 - Rev 10 page 4/110

3Reference safety architecture

This section reports details of the STM32L4 and STM32L4+ Series safety architecture.

3.1 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

Device. Such information includes, among others, application-related assumptions for danger factors, frequency

of failures and diagnostic coverage already guaranteed by the application.

3.2 Compliant item

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

schemes.

3.2.1 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

Remote

controller

Remote

controller

Remote

controller

Remote

controller

Sensor

Actuator

Processing element

Compliant item

STM32

device(s)

Other components might be related to Compliant item, like the external HW components needed to guarantee

either the functionality of 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 IEC61508-4, 3.4.5.

3.2.2 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

UM2305

Reference safety architecture

UM2305 - Rev 10 page 5/110

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

• 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 – CPU_SM_5 and Control flow monitoring in Application software –

CPU_SM_1,

• VMONe: refer to Supply voltage internal monitoring (PVD) – 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.

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

(as per IEC61508-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).

3.2.3 Reference safety architectures - 1oo1

1oo1 reference architecture (Figure 3) ensures safety integrity of Compliant item through combining Device

internal processes (implemented safety mechanisms) with external processes WDTe and VMONe.

1oo1 reference architecture targets safety integrity level (SIL) SIL2.

Figure 3. 1oo1 reference architecture

PEc Actuators

WDTe

Sensors

VMONe

PEoPEi

PEd

UM2305

Compliant item

UM2305 - Rev 10 page 6/110

3.2.4 Reference safety architectures - 1oo2

1oo2 reference architecture (Figure 4) contains two separate channels, either 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. Achievement

of higher safety integrity levels as per IEC61508-2 Table 3 is therefore possible. Appropriate separation between

the two channels (including power supply separation) should be implemented in order to avoid huge impact of

common-cause failures (refer to Section 4.2 Analysis of dependent failures). However, β and βD parameters

computation is required.

1oo2 reference architecture targets SIL3.

Figure 4. 1oo2 reference architecture

Actuators

Sensors

VMONe

PEc PEoPEi

PEd

WDTeVMONe

PEv

PEc PEoPEi

PEd

WDTe

UM2305

Compliant item

UM2305 - Rev 10 page 7/110

3.3 Safety analysis assumptions

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

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

Caution: 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

IEC61508-4,3.5.16:

• a continuous mode (CM) or high-demand (HD) SIL3 safety function (CM3), or

• a low-demand (LD) SIL3 safety function (LD3), or

• a CM or HD SIL2 safety function (CM2), 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 5) in error reaction chain at system

level.

Note: 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

IEC61508-2, 7.4.5.3 must be considered.

Figure 5. Allocation and target for STM32 PST

System-level PST

MCU detection FW reaction SW reaction Actuator reaction

STM32xx Series duty End user duty ….

ASR3: 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.

ASR4: It is assumed that only one safety function is performed or if many, all functions are classified with the

same SIL and therefore they are not distinguishable in terms of their safety requirements.

ASR5: In case of multiple safety function implementations, it is assumed that End user is responsible to duly

ensure their mutual independence.

ASR6: It is assumed that there are no non-safety-related functions implemented in Application software,

coexisting with safety functions.

ASR7: It is assumed that the implemented safety function(s) does (do) not depend on transition of Device to and

from a low-power state.

ASR8: The local safe state of Compliant item is the one in which either:

• SS1: Application software is informed by the presence of a fault and a reaction by Application software itself

is possible.

• SS2: Application software cannot be informed by the presence of a fault or Application software is not able

to execute a reaction.

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

UM2305

Safety analysis assumptions

UM2305 - Rev 10 page 8/110

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

Table 2. SS1 and SS2 safe state details

Safe

state Condition Compliant item

action

System transition to safe

state – 1oo1 architecture

System transition to safe

state – 1oo2 architecture

SS1

Application software is informed

by the presence of a fault and a

reaction by Application software

itself is possible.

Fault reporting

to Application

software

Application software drives

the overall system in its safe

state

Application software in one of

the two channels drives the

overall system in its safe state

SS2

Application software 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 the overall

system in its safe state (“safe

shut-down”) (1)

PEv drives the overall system

in its safe state

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

ASR9: It is assumed that the safe state defined at system level by End user is compatible with the assumed local

safe state (SS1, SS2) for Compliant item.

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

Note: Refer to Section 3.5 Systematic safety integrity and Section 3.6 Hardware and software diagnostics.

ASR11: Compliant item is assumed to be regarded as type B, as per IEC 61508:2, 7.4.4.1.2.

ASR12: It is assumed that dual-bank Flash memory mass erase and reprogramming features are used during

maintenance state of the final system, and not for the implementation of the safety function.

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

3.5 Systematic safety integrity

According to the requirements of IEC 61508 -2, 7.4.2.2, the Route 1S is considered in the safety analysis of

Device(s). As clearly authorized by IEC61508-2, 7.4.6.1, STM32 MCU products can be considered as standard,

mass-produced 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.

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

UM2305

Electrical specifications and environment limits

UM2305 - Rev 10 page 9/110

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

Description Short mnemonic description

Ownership ST: method is available on silicon.

End user: method must be implemented by End user through Application software modification,

hardware solutions, or both.

Detailed

implementation

Detailed implementation sometimes including notes about the safety concept behind the introduction

of the safety mechanism.

Error reporting Describes how the fault detection is reported to Application software.

Fault detection time Time that the safety mechanism needs to detect the hardware failure.

Addressed fault

model

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

information:

• If ranked for Fault avoidance: method contributes to lower the probability of occurrence of a

failure

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

Application software design

Dependency on

Device configuration

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

numbers.

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

Periodicity Continuous : safety mechanism is active in continuous mode.

Periodic: safety mechanism is executed periodically(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.

Test for the

diagnostic

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

efficiency. If no specific procedure applies (as for the majority of safety mechanisms), the field

indicates Not applicable.

Multiple-fault

protection

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

Recommendations

and known limitations

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 IEC61508-2, 7.4.5.3 must be applied.

3.6.1 Arm® Cortex®-M4 CPU

Table 3. CPU_SM_0

SM CODE CPU_SM_0

Description Periodic core self-test software for Arm® Cortex®-M4 CPU.

UM2305

Hardware and software diagnostics

UM2305 - Rev 10 page 10/110

Andere Handbücher für STM32L4 Series

Dieses Handbuch passt für folgende Modelle

Inhaltsverzeichnis

Andere ST Mikrocontroller Handbücher

ST STM8S Bedienungsanleitung

ST STM32 Nucleo Bedienungsanleitung

ST STM8S Bedienungsanleitung

ST STM32CubeL5 Bedienungsanleitung

ST STM32C0 Series Montage- und Bedienungsanleitung

ST STM32L4 5 Series Bedienungsanleitung

ST STM32F401 Discovery Bedienungsanleitung

ST VD6283 Bedienungsanleitung

ST STM32H7 3 Series Montage- und Bedienungsanleitung

ST STM32F7308-DK Bedienungsanleitung

ST ST25DV-I2C Bedienungsanleitung

ST STM32H745I-DISCO Bedienungsanleitung

ST B-L462E-CELL1 Bedienungsanleitung

ST 32F429IDISCOVERY Bedienungsanleitung

ST STM32MP157C-DK2 Bedienungsanleitung

ST SPIRIT1 Bedienungsanleitung

ST STM32F100 Series Bedienungsanleitung

ST STM32F205 series Betriebsanleitung

ST FP-SNS-SMARTAG1 Bedienungsanleitung

ST STEVAL-MKSBOX1V1 Bedienungsanleitung

ST STM8A-DISCOVERY Bedienungsanleitung

ST STM32F101xx series Bedienungsanleitung

ST STM32F10 Series Montage- und Bedienungsanleitung

ST STM32H5 Nucleo-144 Bedienungsanleitung

Beliebte Mikrocontroller Handbücher anderer Marken

Novatek

Novatek NT6861 Bedienungsanleitung

Espressif Systems

Espressif Systems ESP8266 SDK Einrichtungshandbuch

Nuvoton

Nuvoton ISD61S00 ChipCorder Leitfaden

STMicrolectronics

STMicrolectronics ST7 Assembler Linker Bedienungsanleitung

Texas Instruments

Texas Instruments Chipcon CC2420DK Bedienungsanleitung

Lantronix

Lantronix Intrinsyc Open-Q 865XR SOM Bedienungsanleitung

NEC

NEC 78GK0S/K 1+ Series Montage- und Bedienungsanleitung

Mikroe

Mikroe SEMITECH N-PLC Click Montage- und Bedienungsanleitung

Intel

Intel Agilex Bedienungsanleitung

Cypress

Cypress CY4607 HX2VL Bedienungsanleitung

DIGITAL-LOGIC

DIGITAL-LOGIC MICROSPACE Bedienungsanleitung

Texas Instruments

Texas Instruments TMS320F2837 D Series Bedienungsanleitung

CYPRES

CYPRES CY14NVSRAMKIT-001 Bedienungsanleitung

Espressif Systems

Espressif Systems ESP8266EX Betriebsanleitung

Abov

Abov AC33M8128L Bedienungsanleitung

Laird

Laird BL654PA Bedienungsanleitung

Silicon Laboratories

Silicon Laboratories C8051F800 Bedienungsanleitung

Energy micro

Energy micro EFM32 Giant Gecko Starter Kit Bedienungsanleitung