STMicroelectronics STM8AF6268, STM8AF6226, STM8AF6223, STM8AF6266, STM8AF6166 User Manual
...
UM1915
User manual
STM8AF safety manual
Introduction
The microcontrollers of the STM8AF Series, featuring different memory densities, packages
and peripherals, are designed for automotive applications.
This document describes how to use them in the context of a safety-related system
(STM8A-SafeASIL functional safety package), specifying the user's responsibilities for
installation and operation, in order to reach the targeted safety integrity level.
This manual applies to the following STM8AF products:
• the STM8AF62 line, which is the mainstay of the automotive STM8A 8-bit MCU:
– low density devices with 8 Kbytes of Flash memory: STM8AF6223/26
– medium density devices with 16 to 32 Kbytes of Flash memory: STM8AF624x,
STM8AF6266/68, STM8AF612x/4x and STM8AF6166/68
– high density devices with 32 to 128 Kbytes of Flash memory:STM8AF6269/8x/Ax and
STM8AF6178/99/9A
• the STM8AF52 line: STM8AF automotive MCUs with CAN:
– high density devices with 32 to 128 Kbytes of Flash memory: STM8AF52xx and
STM8AF51xx
System designers can avoid going into the details of the ISO26262 functional safety
standard application to the STM8AF microcontrollers by following the indications reported in
this manual.
This manual is written in compliance with ISO 26262. It also indicates how to use the
STM8AF MCUs in the context of other functional safety standards such as IEC 61508.
The safety analysis summarized in this manual takes into account the variation in terms of
memory size, number of internal peripherals and the different packages available among
the different part numbers of STM8AF microcontrollers.
This manual has to be read along with the technical documentation on related part numbers
available on www.st.com/stm8.
October 2019 UM1915 Rev 3 1/43
www.st.com
1
Contents UM1915
Contents
1 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Reference normative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 STM8AF device development process . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 STMicroelectronics standard development process . . . . . . . . . . . . . . . . . . 8
3 STM8AF safety architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Definition of the SEooC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 STM8AF as a SEooC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Assumed safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 The target safety metrics (ASIL, SPFM, LFM and PMHF) . . . . . . . . . . . 11
3.3.2 The assumed target time intervals (FTTI and MPFDI) . . . . . . . . . . . . . . 12
3.4 Electrical specifications and environment limits . . . . . . . . . . . . . . . . . . . . 13
3.5 Systematic safety integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Safety mechanisms/measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.1 STM8AF core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.2 Program Flash memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.3 Data EEPROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.4 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.5 Boot ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.6 Basic enhanced CAN (beCAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6.7 LINUART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6.8 USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.9 I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6.10 SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.11 Analog to digital converter (ADC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.12 Advanced control and general purpose timers (TIM 1 and TIM 2/3) . . . 22
3.6.13 Basic timer (TIM 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.14 GPIO - Ports A/B/C/D/E/F/G/H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2/43 UM1915 Rev 3
UM1915 Contents
3.6.15 Address and Data bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.16 Supply voltage system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.17 Reset and clock control subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.18 Auto-wakeup timer (AWU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.19 Watchdogs (IWDG, WWDG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.20 Debug/SWIM (single wire interface module) . . . . . . . . . . . . . . . . . . . . . 27
3.6.21 Interrupt controller (NVIC and EXTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.22 Latent fault detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.23 Disable and periodic cross-check of unintentional activation
of unused peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Assumption of use (AoU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7.1 List of AoUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Safety analysis results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Hardware random failure analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Safety analysis result customization . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.2 General requirements for FFI (freedom from interferences ) . . . . . . . . . 34
4.2 Dependent failures analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 List of evidences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A Change impact analysis for other safety standards. . . . . . . . . . . . 37
A.1 IEC 61508 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1.1 Architectural categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1.2 Safety metrics re-computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.1.3 Work products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
UM1915 Rev 3 3/43
3
List of tables UM1915
List of tables
Table 1. Terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Table 2. List of STM8AF assumed requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Table 3. Target safety metric values at the item level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Table 4. List of safety mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 5. List of general requirements for FFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Table 6. Some reference architectures for IEC 61508 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table 7. Mapping between this document content and IEC 61508-2 Annex D requirements . . . . . 40
Table 8. IEC 61508 work product grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 9. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4/43 UM1915 Rev 3
UM1915 List of figures
List of figures
Figure 1. Definition of the STM8AF as a SEooC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 2. Relationship between assumptions and SEooC development . . . . . . . . . . . . . . . . . . . . . . 10
Figure 3. STM8AF FTTI allocation and cycle time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 4. Correlation matrix between SIL and ASIL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
UM1915 Rev 3 5/43
5
About this document UM1915
1 About this document
1.1 Purpose and scope
This document is addressed to system designers willing to evaluate the safety of their
solutions. It describes how to use STM8AF microcontrollers in the context of a
system, specifying the user responsibilities for installation and operation, to reach the desired
safety integrity level.
1.2 Terms and abbreviations
safety-related
Acronym Definition
AoU Assumptions to use
ASIL Automotive safety integrity level
CCF Common cause failure
COTS Commercial off-the-shelf
CPU Central processing unit
CRC Cyclic redundancy check
DC Diagnostic coverage
DTI Diagnostic test interval
FIT Failure in time
FTTI Fault tolerant time interval
FMEA Failure mode effect analysis
FMEDA Failure mode effect diagnostic analysis
HFT Hardware fault tolerance
HW Hardware
INTC Interrupt controller
LFM Latent fault metric
MCU Microcontroller unit
MPF Multiple point failures
MPFDI Multiple point fault detection interval
NVIC Nested vector interrupt controller
PMHF Probabilistic metric for random hardware failures
QM Quality management
SFF Safe failure fraction
SIL Safety Integrity level
SEooC Safety element out of context
SPF Single point fault
SPFM Single point fault metric
SW Software
Table 1. Terms and abbreviations
6/43 UM1915 Rev 3
UM1915 About this document
1.3 Reference normative
This document is written in compliance with the ISO 26262 international standard for
functional safety of electrical and/or electronic (E/E) systems within road vehicles.
The versions used as reference is:
• ISO 26262:2018 – Road Vehicles Functional Safety Standards
This safety manual follows the list of recommended contents in Annex A, clause A.3.10 of
ISO 26262-10.
The other functional safety standard considered in this manual is:
• IEC 61508:1-7 © IEC:2010.
1.4 Annexes
[1] UM2138 FMEDA analysis for STM8AF Series MCUs
[2] UM2139 FMEDA handling for STM8AF Series MCUs
UM2138 is a collection of FMEDA snapshots. It is a static document reporting the safety
metrics computed for different detail levels (at microcontroller level and for microcontroller
basic functions) for a given combination of safety mechanisms, a given set of assumptions
and for a given part number. If a FMEDA computation sheet is needed, contact your local
STMicroelectronics sales representative to receive information on expected delivery dates
for specific MCU target part numbers.
UM2139 provides clarifications, guidelines and examples on how to handle the FMEDA
results for STM8AF MCUs.
UM1915 Rev 3 7/43
42
STM8AF device development process UM1915
2 STM8AF device development process
The development process of a microelectronic device used in safety critical applications
must take into account the adequate management to reduce the probability of
systematic faults introduced during the design phase.
ISO 26262-10 Annex A (“A.3.7: Example of techniques or measures to detect or avoid
systematic failures during design of a microcontroller”) act as a guidance in tailoring the
microcontroller standard design and manufacturer process to the compliance of ISO 26262
requirements. The checklist reported in the named Annex A (Tab l e A. 8 ) helps to
related evidences of a given real process.
2.1 STMicroelectronics standard development process
STMicroelectronics (ST) serves four industry domains:
• Standard products.
• Automotive products: ST automotive products are AEC-Q100 compliant. They are
subject to specific stress testing and processing instructions in order to achieve the
required quality levels and product stability.
• Automotive safety: a subset of the automotive domain. ST uses as a reference the
ISO 26262 Road vehicles Functional safety standard. ST supports customer inquiries
regarding product failure rates and FMEDA to support hardware system compliance to
established safety goals. ST provides products that are safe in their intended use,
working in cooperation with customers to understand the mission profile, adopt
common methods and define countermeasures for residual risks.
• Medical products: ST complies with applicable regulations for medical products and
applies due diligence in the development and validation of these products.
STMicroelectronics product development process, compliant with the ISO/TS 16949
standard, is a set of interrelated activities dedicated to transform customer specification
and market or industry domain requirements into a semiconductor device and all its
associated elements (package, module, sub-system, application, hardware, software and
documentation), qualified respecting ST internal procedures and able to be manufactured
using ST internal or subcontracted technologies.
collect all
8/43 UM1915 Rev 3
UM1915 STM8AF safety architecture
3 STM8AF safety architecture
This section describes the safety architecture to implement when using STM8AF
microcontrollers for automotive applications.
3.1 Introduction
The STM8AF microcontroller described in this document is a Safety element out of context
(SEooC), that is, a safety element that can be used in different safety applications.
The aim of this section is to define the context of the analysis in terms of assumptions with
respect to reference safety requirements as also assumptions with respect to the design
external to that SEooC.
As a consequence of the SEooC approach, the goal is not to provide an exhaustive hazard
and risk analysis of the system around the microcontroller, but rather to list the
system-related information (such as the application-related assumptions for dangerousness
factors, frequency of failures and diagnostic coverage already guaranteed by the
application) that have been considered during the following steps of the analysis.
3.1.1 Definition of the SEooC
The automotive industry develops generic elements for different applications and for
different customers. These generic elements can be developed concurrently and by
different companies in different tiers of the supply chain, as a distributed development.
Assumptions are made both on the requirements (including safety requirements) on the
element at higher levels of design and also on the design external to the element.
In a safety context, these elements can be developed as a “Safety Element out of Context”
(SEooC), as described in ISO 26262-10, Clause 9.
According to ISO 26262, a “safety element out of context (SEooC)” is a safety-related
element that is not developed for a specific item, i.e. in the context of a particular vehicle. A
SEooC can be a system, an array of systems, a subsystem, a software component or a
hardware component.
This document considers the STM8AF as a SEooC to whom an ASIL capability is
required, up to and including ASILB, i.e. it can be used in ASILA and ASILB
3.2 STM8AF as a SEooC
The STM8AF is a general purpose RISC microcontroller, suitable for embedded
applications and, in particular, for safety related applications.
For a detailed description of the STM8AF functionality refer to the reference manuals,
available on www.st.com.
In this document, the SEooC is identified as the STM8AF microcontroller (MCU),
referenced as a functional block inserted in a system defined by Figure 1. The MCU acts as
the processing unit of the system, i.e. acquiring field data from sensors, processing
them according to the implemented algorithm, and taking decisions that bring to specific
commands to external actuators. The MCU is connected directly or indirectly to
and actuators through communication buses.
environments.
sensors
UM1915 Rev 3 9/43
42
STM8AF safety architecture UM1915
069
5HPRWH
FRQWUROOHU
5HPRWH
FRQWUROOHU
5HPRWH
FRQWUROOHU
5HPRWH
FRQWUROOHU
6HQVRU
$FWXDWRU
6
6
$
$
3URFHVVLQJHOHPHQW
6(RR&
670$)
069
$VVXPSWLRQV
$VVXPHGUHTXLUHPHQWV
$VVXPSWLRQVRQGHVLJQ
H[WHUQDOWR6(RR&
6(RR&UHTXLUHPHQWV
6(RR&GHVLJQ
Figure 1. Definition of the STM8AF as a SEooC
Other components, like the external HW components needed to guarantee either the
functionality of the STM8AF (external memory, clock quartz) or its safety (e.g. the external
watchdog, voltage supervisors) can be connected to the SEooC.
3.3 Assumed safety requirements
A SEooC is developed, according to ISO 2626-10 clause 9, on the basis of assumptions for
its
intended functionality, use and context, including external interfaces (Figure 2).
Figure 2. Relationship between assumptions and SEooC development
The validity of the aforementioned assumptions is checked, in the context of the actual
item, after the integration of the SEooC.
In this document it is assumed that the concept specification, the hazard and risk analysis,
the overall safety requirement specification and the consequent allocation have determined
the assumed safety requirements reported in Table 2.
10/43 UM1915 Rev 3
UM1915 STM8AF safety architecture
Table 2. List of STM8AF assumed requirements
ID Assumed requirement
AR01 The SEooC is defined as the STM8AF playing the role of processing unit,
Failures in STM8AF HW part leading to wrong execution of the application
AR02
and/or wrong data computations shall be mitigated to fulfil the ASILB
– single-point fault metric at the HW part level at least 90%
as in Figure 1.
program
capability, i.e.
– latent point fault metric at the HW part level at least 60%.
AR03 The STM8AF is assumed to be integrated in a product with a lifetime up to 10
In accordance with ISO 26262-.5, 6.4.8 – Note 1, it is assumed that the
AR04
(Multiple-point fault detection interval) is equal to or lower than the item “power-up to
years.
MPFDI
power-down” cycle (i.e. 1 hour).
AR05 Safety integrity level required for the STM8AF is ASILB.
AR06 It is assumed a FTTI budget allocated to the STM8AFof 250 msec
(1)
.
It is assumed that the STM8AF implements a safe state defined as one in which either:
AR07
– the application software running on the MCU is informed of the
reaction is possible
(2)
, or
– if the application software cannot be informed, the MCU reset is executed
AR08
1. FTTI value is used for reference only. The end user shall verify that the FTTI value of the final application is
2. The end user shall take into account that hardware random failures affecting the STM8AF can compromise
3. According to ISO 26262-1, the safe state is the operating mode of an item without unreasonable level of
4. The possibility for the SEooC to execute either ASIL, QM and non-safety-related functions together has
On the STM8AF SEooC is not executed together with ASIL, QM and/or non-safety-related
software
compatible with the requirements in terms of execution of periodical software-based test (refer to
Section 3.6).
the MCU capability of operating properly (for example failure modes affecting the program counter prevent
the correct execution of software).
risk. The ultimate definition of the safe state depends on the end user application
been excluded because not supported by dedicated hardware.
(4)
presence of a fault and a
(3)
.
3.3.1 The target safety metrics (ASIL, SPFM, LFM and PMHF)
According to AR05, the target for the safety functions is ASILB; therefore every
consideration about absolute and relative safety metrics takes ASILB targets, as reported
in
Tab le 3.
Single-point fault metric (SPFM) ≥ 90% ≥ 90% Relative
Latent-fault metric (LFM) ≥ 60% ≥ 60% Relative
Probabilistic metric for
Even if safety metrics are defined at item (i.e. at car) level for ISO 26262, the
functional safety standard explicitly foresees the computation of those metrics at a lower
level.
Table 3. Target safety metric values at the item level
Safety metric defined
Target value
(
system level)
random hardware failures (PMHF) 100 FIT 10 FIT Absolute
UM1915 Rev 3 11/43
(
Target value
SEooC level)
Metric
type
42
STM8AF safety architecture UM1915
6\VWHPOHYHO)77,
0&8GHWHFWLRQ ):UHDFWLRQ 6:UHDFWLRQ $FWXDWRUUHDFWLRQ
0LFURFRQWUROOHUGXW\ (QGXVHUGXW\ «
069
0LFURFRQWUROOHU)77, 7LPHIRUUHDFWLRQHJ6\VWHPUHVHW
7LPH
In this document any claim and computation in terms of safety metrics is done on the
activity safety scope represented by the SEooC block diagram reported in Tabl e 1.
The budget of the PMHF given to the SEooC must be (if possible) lower than 10% of the
overall PMHF budget of the safety goal, and therefore (for ASILB) the budget for the
STM8AF is 10% * 100 FIT = 10 FIT.
3.3.2 The assumed target time intervals (FTTI and MPFDI)
As illustrated in ISO 26262-1:2001 - Figure 4 - Fault reaction time and fault tolerant time
interval, a system must be able to detect faults and move to safe state before a fault can
become a system level hazard.
In ISO 26262-1, the fault tolerant time interval (FTTI) is defined as the time span in which a
fault (or faults), can be present in a system before a hazardous event occurs.
Moreover, according to ISO 26262-1:2011, the multiple-point fault detection interval
(MPFDI) is the time span to detect multiple-point fault before it can contribute to a
multiple-point failure.
From a system point of view, the STM8AF MCU is a safety-related element, to which a
portion of the FTTI system budget is
assigned to a SEooC (in this case the STM8AF) strongly depends on the application.
Figure 3. STM8AF FTTI allocation and cycle time
associated. As shown in Figure 3, the portion of FTTI
In this document, according to ISO 26262-10, 9.2.3.3 d) it is assumed that any
implemented safety mechanisms related to the STM8AF completes its functions in less
than the assigned FTTI budget time reported in
This value must be considered as a reference, and can be changed by the
MCU/system integrator according to its needs.
It is worth noting that, according to ISO 26262-5, 7.4.3.3, a single point fault must be
detected within the FTTI budget allocated to the component.
In this document, in accordance with ISO 26262-.5:2011, 6.4.8 – Note 1, it is assumed that
the MPFDI is equal to or lower than the item “power-up to power-down” cycle (i.e. one
driving cycle), AR04.
12/43 UM1915 Rev 3
AR06.
UM1915 STM8AF safety architecture
3.4 Electrical specifications and environment limits
The user must not exceed the electrical specification and the environmental limits defined
in the list below, as reported in STM8AF datasheets, to guarantee its own safety integrity:
• absolute maximum rating
• operating conditions.
Due to the large number of STM8AF products, the related user manuals/datasheets are
not listed in this document; the user is responsible to carefully check the above reported
limits in the technical documentation on the related part number available on www.st.com.
3.5 Systematic safety integrity
Due to known device limitations for STM8AF automotive MCUs, the user must follow the
errata sheets available on www.st.com
to avoid the introduction of systematic failures.
3.6 Safety mechanisms/measures
This section lists all the safety mechanisms/measures (hardware, software and application
level) considered in the safety analysis of the microcontrollers of the STM8AF Series.
According to ISO 26262-1, “…a safety mechanism is a technical solution implemented by
Electrical/Electronic (E/E) functions or elements, or by other technologies, to detect faults
or control failures in order to achieve or maintain a safe state”.
It is expected that users are familiar with the STM8AF architecture, and that this document
is used in conjunction with the related device datasheet, user manual and reference
information. Therefore, in order to avoid any mistake and reduce the amount of information
to be shown, no functional details are included in this document.
Note that the part numbers of the STM8AF Series represent different combinations of
peripherals (for instance, some of them are not equipped with CAN peripheral). To reduce
the number of documents and avoid information-less repetitions, the current safety manual
addresses the overall possible peripherals available in the targeted part numbers. Users
have to select which peripherals are really available on their
meaningless recommendations accordingly.
The implementation guidelines reported in the following section are for reference only. Read
the following definitions:
• end user: the final user of STM8AF, in charge of integrating the MCU in a real
application (for example an electronic control board)
• application software: the actual software running on the STM8AF, used to
implement the safety function.
3.6.1 STM8AF core
Periodical core self-test software - CPU_SM_0
Permanent faults affecting the CPU are addressed through a dedicated software test
executing a sequence of instructions and data transfers.
The software test is built around well-known techniques already addressed by ISO
26262-5, D.2.3.1 (“Self-test by software: limited number of patterns (one channel)”).
devices, and discard the
The
UM1915 Rev 3 13/43
42
Loading...