UM3191

User manual

STM32WL series UL/CSA/IEC 60730-1/60335-1 self-test library user guide

Introduction
This document applies to the X-CUBE-CLASSB self-test library set for the STM32WL series dual-core microcontrollers that
include Arm® Cortex®-M0+ and M4 cores. Order code X-CUBE-CLASSB-WL.
Safety has an essential role in electronic applications. The level of safety requirements for components is steadily increasing
and, manufacturers of electronic devices include many new technical solutions in their designs. Techniques for improving safety
are continuously evolving, and are regularly incorporated into updated versions of the safety standards.
The current safety recommendations and requirements are specified in worldwide standards issued by various authorities.
These include: the international electro-technical commission (IEC), Underwriters laboratories (UL), and the Canadian
standards association (CSA) authorities.
Compliance, verification, and certification are the focus of the certification institutes. These include: the German TUV and VDE
(mostly operating in Europe), and the UL and the CSA (targeting mainly the USA and Canadian markets).
Standards related to safety requirements have a very wide scope. These safety standards cover many areas such as:
classification, methodology, materials, mechanics, labeling, hardware, and software testing. Here, the target is just compliance
with the software requirements when testing programmable electronic components, which form a specific part of the safety
standards. These requirements are exceptionally subject of any change when a new upgrade of the standard is released. Also,
there is significant similarity across commonly oriented safety standards that concern the testing of generic parts of
microcontrollers, such as the CPU or memories.
The library presented in this document is based on a partial subset of testing modules developed and applied by ST to satisfy
the stringent IEC 61508 industrial safety standard requirements. These modules are adapted to fulfill the IEC 60730 standard
targeting household safety. That is why this new library adopts a different delivery format to that was used for previous releases.
This format is derived from the industrial safety library, which is currently delivered as a black box pre-compiled object with no
sources but with a clear outer interface definition. The advantage of this immutable solution is that it is compilation tool-chain
agnostic. It is also independent of any other firmware such as HAL, LL, or CMSIS layer. This solution prevents unexpected
compilation results when source code files previously verified on older versions of the library are re-compiled later by any newer
compiler version or combined with the latest firmware drivers. This is generally a common practice.

Table 1. Applicable product

Part number Order code

X-CUBE-CLASSB X-CUBE-CLASSB-WL

UM3191 - Rev 2 - February 2025 www.st.com

For further information, contact your local STMicroelectronics sales office.
 UM3191
General information

1 General information

1.1 Purpose and scope

This document applies to the X-CUBE-CLASSB self-test library set dedicated for STM32WL series dual-core
microcontrollers that embed an Arm® Cortex®-M0+ and an Arm® Cortex®-M4. This X-CUBE-CLASSB-WL
expansion package provides includes two application-independent software test libraries, one dedicated to
Arm® Cortex®-M0+ and one dedicated to Arm®Cortex®-M4 to comply with the UL/CSA/IEC 60730-1 safety
standard. The UL/CSA/IEC 60730-1 safety standard targets the safety of automatic electrical controls used in
association with household equipment and similar electronic applications.
The main purpose of this software library is to facilitate and accelerate:
• user software development
• certification processes for applications which are subject to the associated requirements and certifications

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

The versions of the application-independent software test libraries, self-test libraries, available in the X-CUBE-
CLASSB-WL expansion package (and associated to this manual), STL_Lib_cm0plus.a and STL_Lib_cm4.a
are V4.0.0 and V4.0.1, respectively.

1.2 Reference documents

[1] UM2814: STM32WL Series safety manual dedicated for applications targeting industrial safety
[2] AN4435: Guidelines for obtaining UL/CSA/IEC 60730-1/60335-1 Class B certification in any STM32 application dedicated
to older versions of this library
[3] ES0647: X-CUBE-CLASSB self test library software errata

UM3191 - Rev 2 page 2/63

 UM3191
STM32Cube overview

2 STM32Cube overview

2.1 What is STM32Cube?

STM32Cube is an STMicroelectronics original initiative to improve designer productivity significantly by reducing
development effort, time, and cost. STM32Cube covers the whole STM32 portfolio.
STM32Cube includes:
• A set of user-friendly software development tools to cover project development from conception to
realization, among which are:
– STM32CubeMX, a graphical software configuration tool that allows the automatic generation of
C initialization code using graphical wizards
– STM32CubeIDE, an all-in-one development tool with peripheral configuration, code generation, code
compilation, and debug features
– STM32CubeCLT, an all-in-one command-line development toolset with code compilation, board
programming, and debug features
– STM32CubeProgrammer (STM32CubeProg), a programming tool available in graphical and
command-line versions
– STM32CubeMonitor (STM32CubeMonitor, STM32CubeMonPwr, STM32CubeMonRF,
STM32CubeMonUCPD), powerful monitoring tools to fine-tune the behavior and performance of
STM32 applications in real time
• STM32Cube MCU and MPU Packages, comprehensive embedded-software platforms specific to each
microcontroller and microprocessor series (such as STM32CubeWL for the STM32WL series), which
include:
– STM32Cube hardware abstraction layer (HAL), ensuring maximized portability across the STM32
portfolio
– STM32Cube low-layer APIs, ensuring the best performance and footprints with a high degree of user
control over hardware
– A consistent set of middleware components such as RTOS, FAT file system, LoRaWAN®, sub-GHz
PHY, Sigfox™, KMS, secure engine, and mbed-cryptoRTOS, USB, and graphics
– All embedded software utilities with full sets of peripheral and applicative examples
• STM32Cube Expansion Packages, which contain embedded software components that complement the
functionalities of the STM32Cube MCU and MPU Packages with:
– Middleware extensions and applicative layers
– Examples running on some specific STMicroelectronics development boards

2.2 How does this software complement STM32Cube?

The software expansion package extends STM32Cube by a middleware component to manage specific software-
based diagnostics.
The package provides a generic starting point to help a user to build and finalize application specific safety
solutions. It consists of:
• STL: the self-test library. This provides a binary and some source code to manage the execution of generic
safety tests for the microcontroller. The STL is a standalone unit, which runs independently from any
STM32 software. It collects the self-tests for generic components of the microcontroller.
• User application: This is an STL integration example based on a set of STM32Cube drivers extending the
STL by an application specific test. This part is delivered as full source code to be adapted or extended by
calling of additional application specific modules defined by end user. The example can be used for the
library testing including artificial failing support of all the provided modules.

UM3191 - Rev 2 page 3/63

 UM3191
STL overview

3 STL overview

The following STL overview is exactly the same for the Arm® Cortex®-M0+ and for the Arm®Cortex®-M4. There is
a dedicated STL library for the Arm® Cortex®-M0+ running on the Arm® Cortex®-M0+, and a dedicated STL
library for the Arm®Cortex®-M4 running on the Arm®Cortex®-M4.
The STL is an application-independent software test library released by STMicroelectronics. The aim is to provide
the implementation of a relevant subset of safety mechanisms required by the "Class B" related safety standards
applicable to STM32WL series dual-core microcontrollers. The STL is an HAL / LL independent library, dedicated
to these dual-core microcontrollers. The STL is a compilation tool chain-agnostic, so any standard C-compiler can
compile it.
The STL is an autonomous software. It executes, on application-demand, selected tests to detect hardware
issues, and reports the outcomes to the application.
The STL is delivered partly in object code (for the library itself) and partly in source code for the user interface
definitions and the user parameter settings.

3.1 Architecture overview

The STL dedicated for the Arm® Cortex®-M0+ core tests the Arm® Cortex®-M0+ and its embedded memories.
The STL dedicated for the Arm® Cortex®-M4 core tests the Arm® Cortex®-M4 and its embedded memories.
As shown in the figure below, a system architecture with an end-user application integrating the STL is composed
of:
• User application (indicated in light blue)
• User parameters (indicated in light blue)
• STL scheduler (indicated in yellow): directly accessible by the user application via user APIs (not going
through HAL / LL)
• STL internal test modules: called by the STL scheduler (not visible to the user application).
The STL status information returned to the user application at API level (summarized in Table 2) is:
• Function return value collects result of internal defensive programming checks.
• Test module result value stores the test result information. This partially corresponds to internal status of
the module (see Section 7.3: State machines).

UM3191 - Rev 2 page 4/63

 UM3191
STL overview

Figure 1. STL architecture

User application

STL
Function return value
User
Test result value
APIs

STL User
HAL/LL
STL scheduler parameters

STL STL STL

CPU Arm® core Flash memory SRAM
test modules test module test module

STM32 microcontroller

Legend:

DT67412V1
STL
User

The STL also allows the developer to use the artificial-failing feature. The developer can check the application
behavior by forcing the STL to return a requested test-result value. This feature is available through the specific
user API.
The safety concept for STM32WL dual-core microcontrollers imposes additional requirements to the individual
execution of the STL. An example how to exchange the STL results between the two CPUs via HSEM peripheral
is provided at the integration project example. Refer to the STM32WL dual-core self-test library set safety manual
[1] for guidance.

3.2 Supported products

The STL runs on the STM32WL series dual-core microcontrollers featuring the same design and integration of the
Arm®Cortex®-M0+ and the Arm®Cortex®-M4 cores and their associated embedded memories.

UM3191 - Rev 2 page 5/63

 UM3191
STL description

4 STL description

This section describes basic information on the functionality and performance of the STL. The section also
summarizes restrictions and mandatory actions to be followed by the end user.

4.1 STL functional description

Some test modules can temporarily mask interrupts. For more details, refer to Section 4.2.5: STL interrupt
masking time and to Section 4.3.5: Interrupt management.

4.1.1 Scheduler principle

The scheduler is the API module needed by the user application to execute the STL.
The main scheduler:
• Must be initialized before being used
• Manages:
– The initialization and deinitialization of the applied test modules
– The configuration of the applied test modules
– The reset of the applied test modules.
• Controls the execution of an applied test sequence (API calls)
• Manages "artificial failing" used for user debug and integration tests.
• Ensures the integrity of critical internal data structures via their specific checksums.
The scheduler controls the execution of the following tests:
• CPU tests: no specific initialization or configuration procedures of the CPU test module are required before
any CPU test execution (see Section 7.2: User APIs and Figure 11).
• Flash memory tests operate on the content of the dedicated user configuration structures defining subsets
of the memory to be tested (see Section 7.1: User structures). These structures must be filled by the end
user and the content maintained during both configuration and execution of the flash memory test. The test
module initialization and configuration procedures are mandatory before any flash memory test execution,
see Section 7.2: User APIs and Figure 12.
• RAM memory tests operate on the content of the dedicated user configuration structures defining subsets
of the memory to be tested (see Section 7.1: User structures). These structures must be filled by the end
user and the content maintained during both configuration and execution of the RAM test. RAM test
module initialization and configuration procedures are mandatory before RAM test execution, see
Section 7.2: User APIs and Figure 13.
The STL, via the scheduler API, is called by the user in polling mode. The STL can be called under an interrupt
context, but reentrance is forbidden. In such cases, the STL behavior cannot be guaranteed.
The user application has to consider all the returned information from the STL, provided via a specific predefined
data structure collecting status information. See details in the following table.

UM3191 - Rev 2 page 6/63

 UM3191
STL description

Table 2. STL return information

STL information Value Description

STL_OK Scheduler function successfully executed

Function return value(1) Scheduler defensive programming error (in this case the
STL_KO
test result is not relevant)
STL_PASSED Test passed
Used only for memory testing when the test passed, but
STL_PARTIAL_PASSED the end of memory configuration has not yet been
reached
Test module result value(2)
STL_FAILED Hardware error detection by test module
STL_NOT_TESTED Test not executed
STL_ERROR Test module defensive programming error

1. Refer to STL_Status_t definition in Section 7.1: User structures.

2. See STL_TmSTatus_t in Section 7.1: User structures.

The user application repeatedly applies the call control scheme illustrated in the following figure to program a
sequence of API function calls and so handle the order of the test modules execution.

Figure 2. Single test control call architecture

User application

Function return value

Run single testing
Test result for a single test
User
HAL/LL
parameters

STL

STL scheduler

DT49038V2
Legend:
STL
User

Scheduler and interrupts

The scheduler can be interrupted at any time.

4.1.2 CPU Arm® core tests

The STL includes the CPU test modules listed below, together with a generic description (for information only) of
the test capability:
• TM1L: implements a light pattern test of general-purpose registers
• TM7: implements the pattern and functional tests of both stack pointers: MSP, and PSP
• TMCB: implements test of the APSR status register.
Caution: The STL CPU tests are partitioned in separated test modules. This is not intended to allow partial execution of
the overall available CPU TMs. It is intended as a support feature to allow better CPU test scheduling in the
end‑user applications, for example timing constraints. By default, all available TMs are assumed to be executed.

UM3191 - Rev 2 page 7/63

 UM3191
STL description

CPU Arm® core tests and interrupts

The CPU test modules are interruptible at any time. The TM7 one only applies masking interrupt during the
smallest data granularity time. Refer to Section 4.3.5: Interrupt management for detailed information on CPU TM7
interrupt management.

Dual-core information

The STL_ENABLE_IT flag can either be activated individually on the Arm®Cortex®-M4 or Arm®Cortex®-M0+, or
simultaneously on both Arm®Cortex® cores.

4.1.3 Flash memory tests

Principles
The flash test concerns the embedded flash memory of STM32WL series.
The following structures must be respected to provide correct configuration of the flash memory test.
• Block: a continuous area of 4 bytes (FLASH_BLOCK_SIZE), hard coded by STL.
• Section: a continuous area of 1024 bytes (FLASH_SECTION_SIZE), hard coded by the STL. This has no
link with the memory physical sector. The memory is partitioned in sections. The first section starts at the
first address of the memory, and the following sections are contiguous with each other.
The user must ensure proper calculation and placement of the CRC checksum for each section that is to
be checked during the memory integrity test.
• Binary (named 'user program' in Figure 4): a continuous area of code provided by the compiler. It starts at
the beginning of a section. It usually ends with an incomplete section when the binary area size is not a
multiple of the section size. In all cases, the binary must be 32-bit aligned (see ST CRC tool information
below).
• Subset: a continuous area of contiguous sections defined by the user. The user application can define one
subset or several subsets. A subset has to be defined within a binary area. Its start address has to be
aligned with the beginning of a section. It can only include sections with the corresponding precalculated
CRC values. When the last section of a subset is the last part of the binary, the section may be incomplete.
The user application has to align the end of the subset with the end address of the binary area. If a set of
complete sections is tested exclusively, the subset end address has to be aligned with the end of the last-
tested section.
The subset is calculated as follows:
Subset size = K * FLASH_SECTION_SIZE + L * FLASH_BLOCK_SIZE
where:
– K is an integer greater than 0.
– 0 ≤ L < (FLASH_SECTION_SIZE / FLASH_BLOCK_SIZE) when L > 0 the last section of a binary is
incomplete.
The user application defines single or multiple subsets as well as their associated test sequences.
The STL implements a test of the flash memory with the following principles (based on actual content of the user
configuration structures):
• Tests are performed on sections of one or more subsets defined by the user application.
• Tests are performed either in a row (one shot) or partially in a single atomic step for a number of sections
defined by the user application.
• Test results are based on a CRC comparison between the computed CRC value (calculated during test
execution) and an expected CRC value (calculated before software binary flashing).
The mandatory steps (for the user application) to perform flash memory tests are:
• Test initialization
• Configuration of one or more subsets
• Execution of the test.
Once all subsets are tested, the user needs to reset the flash memory test module to perform the test again.
In the case of an STL_ERROR / STL_FAILED test result, the test module is stuck at the failed memory subset. In
this case, deinitalize, initialize and reconfigure the flash memory test prior to running it again.

UM3191 - Rev 2 page 8/63

 UM3191
STL description

Expected CRC precalculation

The flash memory test is based either on the embedded hardware CRC calculation unit or software CRC
computation algorithm, which is configurable by a flag. The default configuration is with the CRC hardware unit.
To use the software CRC, the flag STL_SW_CRC must be enabled as defined in step 3 in Section 5.5.2: Steps to
build an application from scratch. The CRC is a 32-bit CRC compliant with IEEE 802.3.
Part of the flash memory is reserved for the CRC dedicated area, the size of which depends on the flash memory
size. This area has a field format where each flash memory section has sufficient reserved space to store a 32-bit
CRC pattern. The user must ensure that valid CRC patterns are calculated and stored in the fields for all the
sections to be tested. This is shown in Figure 3.
One expected CRC value is precalculated for each contiguous section of a binary, from binary start to binary end.
This means that the number of testable sections depends on the binary size. Commonly, the binary area is not
aligned with the section size. In that case, the CRC check value of the last incomplete section is precalculated
and tested exclusively over the section part that overlays the binary area.
Preconditions:
• The user program areas have to start at the beginning of a section
• The boundaries of the user program areas must be 32-bit aligned.
• Depending on total flash memory size and on user program size, last program data and first CRC data may
be both stored in the same flash section (without any overlap). In that case, the CRC must be computed on
the user program data only, see example 3 in Figure 4.

ST CRC tool information

ST provides a CRC precalculation tool. This tool is available as a single feature inside the
STM32CubeProgrammer (see Section 6.2.2: CRC tool set-up), which automatically fills the binary with padding
bits (0x00 pattern) for a 32-bit alignment.

UM3191 - Rev 2 page 9/63

 UM3191
STL description

Figure 3. Flash memory test: CRC principle

CRC area CRC area

CRC3 CRC2 CRC1

Program area

...
Section 3

Section 2

Section 1

CRC area

CRC value (32-bit)

Flash memory

DT49041V2
Flash memory section (1 Kbyte)

UM3191 - Rev 2 page 10/63

 UM3191
STL description

Figure 4. Flash memory test: CRC use cases versus program areas
Example Example Example Example
1 3 CRCs_2@ = CRC_START@ + (((User
2 4
ROM_END@ Program 2 start @ - ROM_START@)/
CRCs_3
CRC area CRCs
CRCs CRCs_2 (section size))*4 bytes)
CRCs CRCs
CRCs
CRCs_1
CRC_START@

Flash section
User
program
3 Color legend
User program

User User Pre-calculated CRCs

User program
Program program
program
area 2 Empty Flash section
User
program

User
program
1

ROM_START@

DT49603V2
User programs always start
at the beginning of a section

Use case descriptions illustrated in Figure 4:

• Example 1: the user program starts at the ROM_START address, so CRCs are stored from the
CRC_START address.
• Example 2: the user program starts at the beginning of a section, but not at ROM_START. The stored
CRCs start at the right address of the CRC area.
• Example 3: the user program uses the full program area, so the last program data and the first CRC data
are both stored in the same memory section (without any overlap).
• Example 4: the user program is defined in three separated areas. This requires three separated areas for
the CRC data.
CRC start address computation:
• Real calculation:
CRC_START address = (uint32_t *)(ROM_END - 4 * (ROM_END + 1 - ROM_START) /
(FLASH_SECTION_SIZE) + 1); with FLASH_SECTION_SIZE = 1024
• Textual translation:
CRC_START = ROM_END - (CRC size in bytes) * (number of the memory sections) + 1

Flash memory test and interrupts

Flash memory TM is interruptible at any time.

UM3191 - Rev 2 page 11/63

 UM3191
STL description

Dual-core information
Each core has a dedicated flash area. The above flash memory test information applies to each core. This means
that:
• There is a dedicated CRC area for the Arm®Cortex®-M0+ binary and a dedicated CRC area for the
Arm®Cortex®-M4 binary.
• The flag STL_SW_CRC can be activated either individually on Arm®Cortex®-M0+ or on Arm®Cortex®-M4,
or simultaneously on both Arm®Cortex® cores.
See STL user constraints in Section 4.3.4: CRC resources.

4.1.4 RAM tests

Principles
The RAM test concerns the embedded SRAM memories of STM32WL series.
The following structures must be respected to provide correct configuration of the RAM test.
• Block: a continuous area of 16 bytes (RAM_BLOCK_SIZE), hard coded by the STL (no link with the
memory physical sectors).
• Section: a continuous area of 128 bytes (RAM_SECTION_SIZE), hard coded by the STL.
• Subset: a continuous area, with the size being a multiple of two blocks and with a 32-bit aligned start
address. A subset size is not necessarily a multiple of the section size, because the last part of a subset
can be less than one section.
• Subset size = N * RAM_SECTION_SIZE + 2 * M * RAM_BLOCK_SIZE,
where:
– N is an integer ≥ 0
– M is an integer 0 ≤ M < 4, when M > 0, the size of the last partial subset not aligned with section size.
The user application defines single or multiple subsets as well as their associated test sequences.
The STL implements a RAM memory test with the following principles (based on actual content of the user
configuration structures):
• RAM tests are performed on RAM blocks defined by the user application
• RAM tests are performed either in a row (one shot), or partially in a single atomic step for a number of
sections defined by the user application
• The test implementation is based on the March C- algorithm
The mandatory steps (for the user application) to perform RAM tests are:
• Initialization of RAM test
• Configuration of one or more RAM subsets
• Execution of the RAM test
Once all subsets are tested, the application must reset the RAM test module in order to perform the test again.
In the case of an STL_ERROR / STL_FAILED test result, the test module is stuck in the failed memory subset. In
this case, deinitialize, initialize and reconfigure the RAM prior to running the test again.

RAM test and interrupts

The RAM TM is interruptible at any time except during the execution of the smallest data granularity block as
defined in Section 4.2.5: STL interrupt masking time. This is when the STM32 interrupts and Cortex® exceptions
with configurable priority are temporarily masked by default. Refer to Section 4.3.5: Interrupt management for
detailed information on interrupt management during RAM March-C tests.

March C- test principle and memory backup principle

The RAM test is based on a March C- algorithm where memory is overwritten by specific patterns and then read
back in specific orders. To restore the initial memory content, a backup process is enabled and performed by
default. The backup process can be optionally disabled if it is not required. Refer to Section 4.3.8: RAM backup
buffer for detailed information on the buffer control and allocation.

UM3191 - Rev 2 page 12/63

 UM3191
STL description

Figure 5. RAM test: usage

RAM_END@

RAM backup buffer (32 bytes)

Available RAM for
subset configuration

DT49050V1
RAM_START@

Dual-core information
The above RAM test information applies to each core, and means that:
• The STL_ENABLE_IT compilation switch can be activated either individually on the Arm®Cortex®-M4 or on
Arm®Cortex®-M0+, or simultaneously on both Arm®Cortex® cores.
• The STL_DISABLE_RAM_BCKUP_BUF compilation switch can be activated either individually on the
Arm®Cortex®-M4 or on Arm®Cortex®-M0+, or simultaneously on both Arm®Cortex® cores.
See Section 4.3: STL user constraints in RAM test.

4.2 STL performance data

The data is obtained with the following test set-up:
• STL library compilation details, described in Application: compilation process.
• Projects for performance tests are compiled with IAR Embedded Workbench® for Arm® (EWARM)
toolchain v9.30.1
• Compiled software configuration with:
– HCLK clock set to 48 MHz for both Arm®Cortex®-M0+ and Arm®Cortex®-M4 cores
– Flash memory latency set to two wait states
– NUCLEO-WL55JC1 (MB1389 Rev E )

4.2.1 STL execution timings

A summary of the STL execution timings when an optimal default STL settings are applied is shown in the
following table. The measurements for each API are detailed in Section 9: STL: execution timing details.

UM3191 - Rev 2 page 13/63

 UM3191
STL description

Table 3. Arm®Cortex®-M0+ STL execution timings, clock at 48 MHz

Tested Result in
Conditions
module μs

CPU TM1L, TM7, TMCB 170

1 Kbyte tested 79
Default configuration (STL_SW_CRC not enabled)
Flash 17 Kbytes tested 1016
memory 1 Kbyte tested 465
STL_SW_CRC enabled
17 Kbytes tested 7641
Default configuration (neither 128 bytes tested 175
RAM STL_DISABLE_RAM_BCKUP_BUF, nor
STL_ENABLE_IT are enabled) 32 Kbytes tested 37522

Table 4. Arm®Cortex®-M4 STL execution timings, clock at 48 MHz

Tested Result in
Conditions
module μs

CPU TM1L, TM7, TMCB 126

1 Kbyte tested 70
Default configuration (STL_SW_CRC not enabled)
Flash 17 Kbytes tested 807
memory 1 Kbyte tested 351
STL_SW_CRC enabled
17 Kbytes tested 5658
Default configuration (neither 128 bytes tested 140
RAM STL_DISABLE_RAM_BCKUP_BUF, nor
STL_ENABLE_IT are enabled) 32 Kbytes tested 28999

4.2.2 STL code and data size

The STL code and data sizes are detailed in the following table.

Table 5. Arm®Cortex®-M0+ STL code size and data size (in bytes)

Flash
Flash memory R/W
Configuration Module memory RO-
code data
data

STL_SW_CRC not enabled, stl_user_param_template_cm0plus.o - 4 44

and
stl_util_cm0puls.o 294 4 8
STL_DISABLE_RAM_BCKUP
_BUF not enabled STL_Lib_cm0plus.a 4656 1443 184

stl_user_param_template_cm0plus.o - 4 44
STL_SW_CRC enabled, and
STL_DISABLE_RAM_BCKUP stl_util_cm0puls.o 150 2 4
_BUF not enabled
STL_Lib_cm0plus.a 4656 1444 184

Table 6. Arm®Cortex®-M4 STL code size and data size (in bytes)

Flash memory Flash memory R/W

Configuration Module
code RO-data data

STL_SW_CRC not enabled, stl_user_param_template_cm4.o - 6 44

and
stl_util_cm4.o 286 - 8
STL_DISABLE_RAM_BCKUP
_BUF not enabled STL_Lib_cm4.a 4856 1456 184

UM3191 - Rev 2 page 14/63

 UM3191
STL description

Flash memory Flash memory R/W

Configuration Module
code RO-data data

stl_user_param_template_cm4.o - 6 44
STL_SW_CRC enabled, and
STL_DISABLE_RAM_BCKUP stl_util_cm4.o 150 - 4
_BUF not enabled
STL_Lib_cm4.a 4856 1456 184

4.2.3 STL stack usage

The minimum stack-available space required by the STL to execute available APIs is 200 bytes.

4.2.4 STL heap usage

The STL never uses dynamic allocation, therefore the heap size is independent of the STL.

4.2.5 STL interrupt masking time

The STM32 interrupts, and Cortex® exceptions with configurable priority, are masked multiple times by the STL
during the execution of CPU TM7 and RAM tests. As shown in the following table, the maximum interrupt masking
time is obtained for a RAM test.

Table 7. Cortex®-M0+ STL maximum interrupt masking information

Duration (max)
Tested module Steps
in μs

Each execution of STL_SCH_RunRamTM function performs a series of interrupt masking

during partial steps of the test at the following time durations:
• 16 μs for backup buffer +
RAM 16
• 13 μs for the first RAM block to be tested
• 15 μs for each middle RAM block to be tested1
• 13 μs for the last RAM block to be tested
TM7 11 Masked twice for 11 μs

1. Number of RAM blocks (multiple of two RAM_BLOCK_SIZE is required) involved with each RAM test execution depends on
content of user structures (size of defined subset(s) versus atomic step – see Section 4.1.4: RAM tests).

Table 8. Cortex®-M4 STL maximum interrupt masking information

Duration (max)
Tested module Steps
in μs

Each execution of STL_SCH_RunRamTM function performs a series of interrupt masking

during partial steps of the test at the following time durations:
• 13 μs for backup buffer +
RAM 13
• 11 μs for the first RAM block to be tested
• 12 μs for each middle RAM block to be tested 1
• 11 μs for the last RAM block to be tested
TM7 9 Masked twice for 9 μs

4.3 STL user constraints

The end user needs to consider interference between the application and the STL. The consequences of ignoring
this are possible false STL error reporting, and/or application software execution issues.
Accordingly, to prevent any interference the application software and the STL integration must comply with each
constraint listed in this section.

UM3191 - Rev 2 page 15/63

 UM3191
STL description

4.3.1 Dual-core STL constraints

The STL relies on HW resources, RCC (see Section 4.3.3: RCC resources) and CRC (see Section 4.3.4: CRC
resources), shared between the Arm®Cortex®-M0+ and Arm®Cortex®-M4 cores. This implies that applications
running on each core must correctly manage these hardware resources to avoid conflicts.
For example, this is done using the semaphore (HSEM) as shown in the applications delivered in the release
package to demonstrate the STL execution.

4.3.2 Privileged-level
The CPU TM7 and the RAM TM must be executed with privileged level Arm®Cortex®-M0+ and Arm®Cortex®-M4
cores, in order to be able to modify certain core registers (for example the PRIMASK register) else these TMs
return STL_ERROR.

4.3.3 RCC resources

During STL execution, the RCC is configured to always provide a clock to the CRC hardware unit during STL
initialization and optionally during STL Flash test module execution. This means that:
• when the STL returns, it restores the user RCC clock setting (enabled or disabled) for the CRC unit.
• the user application should be careful when configuring the RCC during STL execution by saving/restoring
the STL settings.

Dual-core information
In view of the above, when the user application runs on the same core as the STL, attention should be given to
the RCC configuration. Moreover, even when the user application and the STL run on different cores, the STL
might report false errors if one core updates the CRC clock setting in the RCC configuration while the other core
executes STL tests. This constraint between the two cores can be removed by using SW CRC as described in
Section 4.3.4: CRC resources, except for the STL_SCH_Init function, for which the HW CRC is used by default.

4.3.4 CRC resources

The STM32 CRC hardware unit is used during STL execution in two different cases:
• During execution of STL initialization (function STL_SCH_Init), the use of the CRC hardware unit in this
phase cannot be modified by the application software, so the STL_SW_CRC flag has no impact during
execution of the STL_SCH_Init function.
• During execution of the flash memory test module, the application can choose between hardware and
software calculation of the CRC checksums by means of the STL_SW_CRC flag. By default, hardware
CRC is used (the STL_SW_CRC flag is disabled).
The use of hardware CRC means that:
• Before calling the STL, the user must save any specific CRC unit configuration. The user configuration has
to be restored after the STL execution.
• During the STL execution, the hardware unit is configured and used for STL needs (the user application
must save/restore the STL settings when using the unit while interrupting the STL execution).

Dual-core information
In view of the above, when the user application runs on the same core as the STL, attention should be given to
the HW CRC configuration. Moreover, even when the user application and the STL runs on different cores, the
STL might report false errors if one core updates the HW CRC setting while the other core executes STL tests.
Activation of the STL_SW_CRC flag can be used as a solution to avoid conflict on HW resources (RCC and CRC)
at the core or between them, except for the STL_SCH_Init function, for which the HW CRC is used by default.
The STL_SW_CRC flag can be activated either individually on the Arm®Cortex®-M0+ or Arm®Cortex®-M4 or on
both simultaneously.

4.3.5 Interrupt management

Dual-core information

The STL disables STM32 interrupts and Cortex® exceptions with configurable priority only on the core that runs
the STL.

UM3191 - Rev 2 page 16/63

 UM3191
STL description

Escalation mechanism - Arm® Cortex® behavior reminder

When the STL disables STM32 interrupts, and Cortex® exceptions with configurable priority, remember that an
Arm® Cortex® escalation to HardFault might occur. In this case, the HardFault handler is called instead of the fault
handler.

Interrupt and CPU TM7

By default, the STM32 interrupts and Cortex® exceptions with configurable priority are temporarily masked during
the CPU TM7 execution within smallest data granularity (a few instruction blocks), except if the user application
activates the STL_ENABLE_IT compilation switch (see Section 5.5.2: Steps to build an application from scratch).
If the STL_ENABLE_IT flag is activated, the correct STL CPU TM7 behavior is not guaranteed. The end user is
responsible for managing interferences between the STL and its application software that could lead the STL to
generate false test error reporting or not to detect hardware failures.

Interrupt and RAM March C- tests

By default, the STM32 interrupts and Cortex® exceptions with configurable priority are masked during the RAM
March C- tests, except if the user application activates the STL_ENABLE_IT compilation switch (see
Section 5.5.2: Steps to build an application from scratch).
If the STL_ENABLE_IT flag is activated:
• The correct STL RAM test behavior is not guaranteed, as the application may overwrite the STL-tested
RAM content during its interrupt treatment. The end user is responsible for managing interferences
between the STL and its application software that could lead the STL to generate false RAM test error
reporting.
• The behavior of the user application software can be compromised. Wrong data may be read or used from
RAM locations that are being modified by the STL March C- test.

Interrupt and general purpose registers

During STL execution, the application must save and restore the general-purpose registers in the STM32 interrupt
and Cortex® exception with configurable priority service routine to ensure correct STL behavior and prevent any
false error reporting.

How STL masks the interrupts

To mask the interrupts, the STL sets the PRIMASK register bit to 1. Setting this bit to 1 boosts the current
execution priority to 0, preventing the activation of all exceptions with configurable priority. Thus when the current
execution priority is boosted to a particular value, all exceptions with a lower or equal priority are masked.

4.3.6 DMA
The application must manage the DMA to avoid unwanted accesses to the RAM bank during the STL March C-
test. In this case:
• DMA writes can disturb the STL test causing false error reporting
• DMA reads can return wrong data due to STL overwrites to DMA dedicated RAM sections.

4.3.7 Supported memories

The STL memory tests provided (Flash TM and RAM TM) must only be executed on STM32 internal embedded
memories. The STL library flow must be executed from the internal embedded memory only.

4.3.8 RAM backup buffer

The backup process is enabled by default during RAM tests to preserve the RAM content. The user must then
reserve a specific area for the RAM backup buffer at compilation time which must be allocated outside RAM
subset configuration. There is only one RAM backup buffer defined for the test. The RAM backup buffer area is
also tested by the March C- algorithm each time a RAM run test is called (prior to any subset defined by the user
is tested).

UM3191 - Rev 2 page 17/63

 UM3191
STL description

The backup process can be optionally disabled either permanently by activating the compilation switch
STL_DISABLE_RAM_BCKUP_BUF (see Section 5.5.2: Steps to build an application from scratch) or temporarily
suppressed by specific control sequence (see note below). In this case, it is the resposibilty of the end-user to
guarantee that the application software does not consume data destroyed by the March C- test. This option can
be used to speed up testing of those RAM areas where users do not need to preserve the memory content.
Note: For a temporary suppression of the RAM backup buffer, the user must follow a set sequence:
1. Change the STL_pRamTmBckUpBuf variable value to overwrite it by NULL, while keeping a backup of the
original value (default value stored by the STL).
2. The RAM test must then be restarted. To do so the user can use one of the APIs which force the RAM test
into either RAM_IDLE or RAM_INIT state (see state diagrams in Section 7.3: State machines) .
To remove the backup suppression, the user must perform the same steps as above while restoring the default
value of STL_pRamTmBckUpBuf to its original value and reinitialize the RAM test.

Dual-core information
The user application of one core should be careful to define RAM subsets with RAM addresses either:
• Not shared with the other core
• Shared with the other core, in which case the other user application must not modify the content of the
shared RAM subset addresses during STL execution. This option is not recommended because of its
potential complexity.

4.3.9 Memory mapping

Due to the RAM test module and March C method design, the user must ensure that the “read only” data of the
STL is located in the flash memory. This must be done via a proper adaptation of the associated linker file .
The examples below are for EWARM and STM32CubeIDE.

EWARM .icf file adaptation example

place in ROM_region { readonly };

STM32CubeIDE .ld file adaptation example

.rodata :
{
……
} >ROM

Note: Usually the default configuration locates “read only” data in flash memory.

4.3.10 Processor mode

The STL CPU TM7 must be executed in thread mode in order to set the active stack pointer to the process stack
pointer. If the STL is not executed in thread mode, the CPU TM7 returns STL_ERROR.

4.4 End-user integration tests

This section describes the mandatory tests to be executed by the end user during the verification phase. These
tests guarantee that the STL is correctly integrated in the application software.

4.4.1 Test 1: correct STL execution

The end user must use the expected function-return value and the expected test-module result value (see
Section 7.2: User APIs) to check that each planned diagnostic function has been correctly executed. This
concerns both the test modules execution and all their configuration actions.

UM3191 - Rev 2 page 18/63

 UM3191
STL description

4.4.2 Test 2: correct STL error-message processing

The end user must check that any error information produced by the STL function-return and test-module result
values is correctly interpreted as unexpected behavior, and correctly handled in its application software. Error
information refers to values different to the expected value, see Section 7.2: User APIs). During the verification,
the artificial-failing feature must be used to emulate the generation of incorrect test-module result values related to
associated individual software diagnostics (CPU tests, RAM test, flash memory test), for each of the individual
functions used.
This process cannot be considered as an exhaustive simulation of actual CPU failures on real devices but rather
a testing interface of the implemented APIs.
Note: In some circumstances, experts performing the safety assessment of final systems embedding the STL might
require exhaustive simulation to demonstrate STL capability to capture corruption of STM32 registers or
memories injected intentionally during debugging the STL code. To perform these tests is practically impossible
for any end user due to STL object delivery format. This specific testing was done for all the provided TMs
during the STL certification process and its passing is recorded at internal test reports and guaranteed by the
valid certificate issued for this ST firmware.

UM3191 - Rev 2 page 19/63

 UM3191
Package description

5 Package description

This section details the X-CUBE-CLASSB-WL expansion package content and its correct use.

5.1 General description

X-CUBE-CLASSB-WL is a software expansion package for STM32WL series dual-core microcontrollers.
It provides a complete solution that helps end customers to build a safety application:
• An application-independent software test library is available:
– partly as object code: STL_Lib_cm0plus.a and STL_Lib_cm4.a, the library itself
– partly as source file: stl_user_param_template_cmxxx.c and stl_util_cmxxx.c
– with two sets of three header files: stl_stm32_hw_config_cmxxx.h, stl_user_api_cmxxx.h,
and stl_util_cmxxx.h
• A user application example, available as source code.
X-CUBE-CLASSB-WL has been ported on the products listed in Section 3.2: Supported products.
The software expansion package includes a sample application that the developer can use to start experimenting
with the code. It is provided as a zip archive containing both source code and library.
The following integrated development environments are supported:
• IAR Embedded Workbench® for Arm® (EWARM)
• Keil® microcontroller development kit (MDK-ARM)
• STM32CubeIDE.

5.2 Architecture
The components of the X-CUBE-CLASSB-WL expansion package are illustrated in Figure 6.

Figure 6. Software architecture overview

STL sample application

PC software
Application level

Self-test library (STL)

Utilities
Middleware level

Board support HW abstraction

package (BSP) layer (HAL) CMSIS

Drivers
DT49051V1

Legend:
STL
User

5.2.1 STM32Cube HAL

The HAL driver layer provides a simple, generic, multi-instance set of APIs (application programming interfaces)
to interact with the upper layers (application, libraries, and stacks).
It comprises generic and extension APIs. It is directly built around a generic architecture and allows the layers that
are built upon, such as the middleware layer, to implement their functionalities without dependencies on the
specific hardware configuration of a given microcontroller.
This structure improves the library code re-usability and guarantees an easy portability to other devices.

UM3191 - Rev 2 page 20/63

 UM3191
Package description

5.2.2 Board support package (BSP)

The software package needs to support the peripherals on the STM32 boards, apart from the MCU. This software
is included in the board support package (BSP). This is a limited set of APIs that provides a programming
interface for some specific board components, such as the LED and the user button.

5.2.3 STL
A significant part of the STL, available at middleware level, is a black box that manages the software-based
diagnostic test. It is independent from the HAL, BSP, and CMSIS, even if the STL integration example relies on
some HAL drivers.

5.2.4 User application example

Reference projects provided in the example show how to integrate a possible sequence of the STL test module
calls into an application when adopting different IDEs, verify the returns of the APIs, and emulate their failure
responses artificially. Additionally, a specific module for testing the clock system by applying a monitoring method
compliant with the "Class B" standard requirements is included with a full source code to extend the available
library set. It demonstrates how the library can be extended by specific tests or modules entirely defined by the
end user.
The example also shows a possible way to differentiate between the overall initial startup test and the sequence
of partial tests performed periodically during application runtime.

5.2.5 STL integrity

The integrity of the STL content is ensured by hash SHA-256.

UM3191 - Rev 2 page 21/63

 UM3191
Package description

5.3 Folder structure

A top-level view of the structure is shown in Figure 7.

Figure 7. Project file structure

x.y.z is an abstraction layer for

the version used

BSP drivers for NUCLEO-WL55JC1

STM32WL CMSIS and HAL drivers

STL content with the library

object file and associated
headers and sources

STL integration
example
DT72476V1

UM3191 - Rev 2 page 22/63

 UM3191
Package description

5.4 APIs

5.4.1 Compliance

Interface compliance

The library part of the STL, not delivered in source code, has been compiled with IAR Embedded Workbench® for
Arm v9.30.1. The compilation is done with --aeabi and --guard_calls compilation options to fulfill AEABI
compliance as described in “AEABI compliance” of the EWARM help section.
To comply with the IEC 61508 functional safety standard, the industrial version of the self test library (X-CUBE-
STL) certified by TUV was compiled by safety certified EWARMFS version of the IAR™ compiler exclusively.
Sources of this X-CUBE-CLASSB self test library dedicated to home appliances are based on a subset of
modules taken from the industrial version of the library and have been adapted to comply with the IEC 60730-1
standard. This library can be linked-against any standard C-compiler.

Safety guidelines

To fulfill the safety guidelines compliance as described in the IAR Embedded Workbench® safety guide (advice
2.1-1, 2.2-5, 2.4-1a and 5.4-3) and the Keil® safety manual (§4.9.2), the compliance is done with --strict, --
remarks, --require_prototypes and --no_unaligned_access compilation options.

Library compliance
The library part of the STL (not delivered in source code) is compliant with C standard library ISO C99.
It has been compiled with the IAR™ option. Language C dialect = Standard C.

Arm® compiler C toolchain vendor/version independency

The STL user API refers only to the “uint32_t” and “enum” C types:
• “uint32_t” C type is a fixed type size of 32 bits according to C standard C99
• “enum” C type size, according to C standard C99, is defined by the implementation. It must be able to
represent the values of all the enumeration members. In the STL interface, the enum type values are
unsigned integers, smaller than or equal to (232 - 1). The user must ensure that the enum type value can
hold a 32-bit value.

5.4.2 Dependency
The STL library calls the memset standard C library function.
Furthermore, the IAR™ EWARM toolchain compiler is used to compile the STL library. This compiler may, under
some circumstances, call the following standard C library functions: memcpy, memset, and memclr. This
behavior is intrinsic to the IAR™ EWARM toolchain compiler. It is not possible to disable or avoid it.
As a result, when linking the STL library the user must ensure that these standard C library functions are defined.
The user can use either the functions provided by the toolchain or the user ones.

5.4.3 Details
Detailed technical information about the available APIs can be found in Section 7.2: User APIs, where the
functions and parameters are described.

5.5 Application: compilation process

5.5.1 Steps to build a delivered STL example

1. Install the STMicroelectronics CRC tool (see Section 6.2.2: CRC tool set-up) or other CRC tool that generate
an adequate structure necessary for proper execution of the flash test.
2. Select a project example and open it.

UM3191 - Rev 2 page 23/63

 UM3191
Package description

3. For each target configuration, STM32WL55JC1_Nucleo_CM0PLUS and STM32WL55JC1_Nucleo_CM4,

launch the build that compiles the binary and post build command invokes CRC tool to calculate and allocate
the CRC results. In case of error, check the CRC tool path. For details see Section 5.5.2: Steps to build an
application from scratch.
4. Load the two coupled binaries.
5. Execute the example code.
Boot the board and check the result. LED1 shows the status of STL running on Arm®Cortex®-M0+, LED2 on
Arm®Cortex®-M4:
• LED toggles quickly and regularly: test result is as expected.
• LED toggles irregularly: there is an error.
If any test returns a failure result, the LED flashes once every 2 sec. If the STL detects a defense programming
error, the LED flashes once every 4 sec.
The FailSafe_Handler procedure is then called with a parameter keeping the identification code of the failed
module
Note: The codes definitions are given in the stl_user_api_cmxxx.h file, in the case of a defensive programing
failure, the DEF_PROG_OFFSET is added to the module code. User can adapt or extend the set of definitions
applied by the STL example there.

UM3191 - Rev 2 page 24/63

 UM3191
Package description

5.5.2 Steps to build an application from scratch

To build an application from scratch, follow the steps listed below:
1. Create new application project with a suitable directory structure and with all the appropriate packages. Use
STM32CubeMX tool to make it automatically.
2. If any automated include options of the STL in the project is not supported by the STM32CubeMX tool, copy
and paste the content of the ...Middleware\ST\CM0PLUS and ...Middleware\ST\CM4 directories from the
delivered STL example into the application project directories structure on Arm®Cortex®-M0+ and
Arm®Cortex®-M4 cores. Refer to Section 5.3: Folder structure. In this case, modify the project setting
manually while following the next steps:
– Add all the STL source files located at the Src directories into both CM0PLUS and CM4 projects.
– Assign the Inc in directories as additional directories to be listed in both CM0PLUS and CM4 projects.
– Force the linker to include the library object files located at the Lib directories as additional libraries.
Note: This second step is necessary only when no automatic including option is supported by the CubeMX tool
else it is fully performed by the tool - then there is no need for any manual intervention as described above -
user can leave them out and continue by Step 3
3. If needed, add the next optional preprocessor compilation switches at both project settings:
– Option to enable STL_DISABLE_RAM_BCKUP_BUF, if the RAM backup buffer is not used (in this case
the RAM data of the tested subsets are destroyed). If not activated, the RAM backup buffer is used by
default. In such cases, the "backup_buffer_section" section must be defined in the linker scatter file.
– Option to enable STL_SW_CRC: this is where the user application selects the software CRC . If not
activated, the hardware CRC calculation is used by default.
– Option to enable STL_ENABLE_IT: this is where the user application enables the STM32 interrupts
during the CPU TM7, and RAM test. If not activated, the interrupts are masked during these tests. See
Section 4.3.5: Interrupt management and Section 4.1.4: RAM tests.
4. Check the configuration of the flash memory density.
It is mandatory to set the correct range of the memory for the project at
stl_user_param_template_cmxxx.c file. Update the STL_ROM_END_ADDR there especially to ensure
coherency with the associated linker scatter file and the CRC tool script (see step 6.).
5. Develop the user STL flow control. It is done by implementing the proper sequence of API calls repeated at
periodical cycles, as required by the defined safety task.
It is mandatory to ensure a proper filling of all the associated user structures to control the memory tests and
apply a correct check of the STL return information. Refer to Section 7: STL: User APIs and state machines.
6. Apply the CRC tool to build the CRC area content necessary for the CRC calculation for both the projects.
Refer to Section 6.2.2: CRC tool set-up.
Execute a proper command line of the STM32CubeProgrammer. This can be done automatically within the
compilation process by invoking the IDE post build feature action as seen in Figure 8 and Figure 9.
7. Compile, load, and execute the binary.
Artificial failing APIs can be used to debug a correct behavior of the programmed STL flow if the STL detects a
hardware failure.

UM3191 - Rev 2 page 25/63

 UM3191
Package description

Figure 8. IAR™ post-build actions screenshot

Figure 9. CRC tool command line

STM32_Programmer_CLI.exe s- l "$PROJ_DIR$/M4_Out/Exe/CM4_Project.out” 0x08000000 0x0820000 0x400

Executable tool name Compiled binary path Flash end @ + 1

Mandatory option Flash start @ Section size-

Mandatory value
DT72478V1

Note: The CLI command line is example for Arm®Cortex®-M4 core. It has to be adapted accordingly in the project for
Arm®Cortex®-M0+ e.g.: STM32_Programmer_CLI.exe -sl "$PROJ_DIR$/CM0Plus_Out/Exe/
CM0Plus_Project.out" 0x08020000 0x08040000 0x400.

UM3191 - Rev 2 page 26/63

 UM3191
Hardware and software environment setup

6 Hardware and software environment setup

6.1 Hardware setup

The STM32 Nucleo boards provide an affordable and flexible way for users to try out new ideas and build
prototypes with any STM32 microcontroller lines. The ARDUINO® connectivity support and ST morpho headers
make it easy to expand the functionality of the STM32 Nucleo open development platform with a wide choice of
specialized expansion boards. The STM32 Nucleo board does not require any separate probe as it integrates the
ST-LINK/V2-1 debugger/programmer. The STM32 Nucleo boards comes with the STM32 comprehensive
software HAL library together with various packaged-software examples.
Details about the STM32 Nucleo boards are available from the http://www.st.com/stm32nucleo web page.

Figure 10. STM32 Nucleo board example

The following components are needed:

• NUCLEO-WL55JC1 (MB1389 Rev E ) development board
• USB type A to Micro-B USB cable to connect the development board to the PC.

6.2 Software setup

This section lists the minimum requirements for the developer to set up the SDK, to run the sample scenario, and
to customize applications.

6.2.1 Development tool-chains and compilers

Select one of the IDEs supported by the STM32Cube software expansion package.
Read the system requirements and setup information provided by the selected IDE provider.
Check the projects Release_Notes.html file inside the release package, and refer to the chapter IDE compatibility,
if it exists.

UM3191 - Rev 2 page 27/63

 UM3191
Hardware and software environment setup

6.2.2 CRC tool set-up

ST provides a CRC tool, available as a single feature inside the STM32CubeProgrammer, used for flash memory
testing. Other CRC tools can be used, provided they fulfill the requirements detailed in Expected CRC
precalculation.
Tool installation procedure:
1. Select STM32CubeProgrammer on the dedicated web page available on www.st.com
2. Install the package.
The easiest way is to add the tool path in the environment variable (computer administration rights are required).
If not, the path must be added directly in the project for compilation, in the post-build option.

UM3191 - Rev 2 page 28/63

 UM3191
STL: User APIs and state machines

7 STL: User APIs and state machines

7.1 User structures

The structures are defined in stl_user_api_cm0plus.h and stl_user_api_cm4.h. It is forbidden to
change the content of these files.
Structures detailed hereafter are copies of the stl_user_api_cm0plus.h and stl_user_api_cm4.h
content:
typedef enum
{
STL_OK = STL_OK_DEF, /* Scheduler function successfully executed */
STL_KO = STL_KO_DEF /* Scheduler function unsuccessfully executed
(defensive programming error, checksum error). In this case
the STL_TmStatus_t values are not relevant */
} STL_Status_t; /* Type for the status return value of the STL function execution */

typedef enum
{
STL_PASSED = STL_PASSED_DEF, /* Test passed. For Flash/RAM, test is passed and end of
configuration is also reached */
STL_PARTIAL_PASSED = STL_PARTIAL_PASSED_DEF, /* Used only for RAM and Flash testing.
Test passed, But end of Flash/RAM
configuration not yet reached */
STL_FAILED = STL_FAILED_DEF, /* Hardware error detection by Test Module */
STL_NOT_TESTED = STL_NOT_TESTED_DEF, /* Initial value after a SW init, SW config,
SW reset, SW de-init or value when Test Module
not executed */
STL_ERROR = STL_ERROR_DEF /* Test Module unsuccessfully executed (defensive programing
check failed) */
} STL_TmStatus_t; /* Type for the result of a Test Module */

typedef enum
{
STL_CPU_TM1L_IDX = 0U, /* CPU Arm Core Test Module 1L index */
STL_CPU_TM7_IDX, /* CPU Arm Core Test Module 7 index */
STL_CPU_TMCB_IDX, /* CPU Arm Core Test Module Class B index */
STL_CPU_TM_MAX /* Number of CPU Arm Core Test Modules */
} STL_CpuTmxIndex_t; /* Type for index of CPU Arm Core Test
Modules */

typedef struct STL_MemSubset_struct

{
uint32_t StartAddr; /* start address of Flash or RAM memory subset */
uint32_t EndAddr; /* end address of Flash or RAM memory subset */

struct STL_MemSubset_struct *pNext; /* pointer to the next Flash or RAM memory subset
- to be set to NULL for the last subset */
} STL_MemSubset_t; /* Type used to define Flash
or RAM subsets to test */

typedef struct
{
STL_MemSubset_t *pSubset; /* Pointer to the Flash or RAM subsets to test */
uint32_t NumSectionsAtomic; /* Number of Flash or RAM sections to be tested
during an atomic test */
} STL_MemConfig_t; /* Type used to fully define Flash or RAM test configuration */

typedef struct
{
STL_TmStatus_t aCpuTmStatus[STL_CPU_TM_MAX]; /* Array of forced status value
for CPU Test Modules */
STL_TmStatus_t FlashTmStatus; /* Forced status value for Flash Test Module */
STL_TmStatus_t RamTmStatus; /* Forced status value for RAM Test Module */
} STL_ArtifFailingConfig_t; /* Type used to force Test Modules status to a specific
value for each STL Test Module */

UM3191 - Rev 2 page 29/63

 UM3191
STL: User APIs and state machines

7.2 User APIs

The following APIs are declared in the files stl_user_api_cm0plus.h and stl_user_api_cm4.h . It is
forbidden to change the content of these files.
Caution: For pointers defined by the user application and used as STL API parameters, the user application must set
valid pointers, maintain pointer availability, and check the pointer integrity. The STL does not copy the pointer
content, and accesses directly to the memory addresses defined by the application.
This applies during the overall STL execution. For example, the pointers to access the content of structures that
keep the configuration of the memory tests must be maintained. They are still used by the STL_SCH_run_xxx
functions, even if they are not always part of the input parameter list when an API associated with these tests is
called.
For more details about proper API sequence calls see Section 7.3: State machines and Section 8: Test
examples.

7.2.1 Common API

The following sections present details on common APIs.

7.2.1.1 STL_SCH_Init
Description: initializes the scheduler. It can be used at any time to reinitialize the scheduler (it resets all tests).
Declaration: STL_Status_t STL_SCH_Init(void).

Table 9. STL_SCH_Init input information

Allowed states Parameters

CPU TMx: all

Flash TM: all -
RAM TM: all

Table 10. STL_SCH_Init output information

STL_Status_t return value

Returned state
Value Comments

CPU TMx: CPU_TMx_CONFIGURED

STL_OK Function successfully executed Flash TM: FLASH_IDLE
RAM TM: RAM_IDLE
Source of defensive programming error:
STL_KO No state change
• STL internal data corrupted

Additional information: there is no specific CPU initialization function for CPU test modules.
Note: This function uses hardware CRC as explained in Section 4.3.4: CRC resources.

7.2.2 CPU Arm® core testing APIs

7.2.2.1 STL_SCH_RunCpuTMx
Description: runs one of the CPU test modules.
Declaration: STL_Status_t STL_SCH_RunCpuTMx(STL_TmStatus_t *pSingleTmStatus) where TMx
can be one of TM1L, TM7 or TMCB.

UM3191 - Rev 2 page 30/63

 UM3191
STL: User APIs and state machines

Table 11. STL_SCH_RunCpuTMx input information

Parameters
Allowed states
Value Comments

CPU_TMx_CONFIGURED *pSingleTmStatus See Caution

Table 12. STL_SCH_RunCpuTMx output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_PASSED -
STL_FAILED -
Source of defensive
programming error:
• STL internal data
STL_OK Function successfully executed corrupted CPU_TMx_CONFIGURED
• Software is not
STL_ERROR executed with
privileged level for CPU
TM7
• Software is not
executed in thread
mode for CPU TM7
Possible source of defensive
programming error:
STL_KO Not relevant Value must not be used No state change
• pSingleTmStatus = NULL
• STL internal data corrupted

7.2.3 Flash memory testing APIs

7.2.3.1 STL_SCH_InitFlash
Description: initializes flash memory test.
Declaration: STL_Status_t STL_SCH_InitFlash(STL_TmStatus_t *pSingleTmStatus)

Table 13. STL_SCH_InitFlash input information

Parameters
Allowed states
Value Comments

FLASH_IDLE
FLASH_INIT *pSingleTmStatus Caution
FLASH_CONFIGURED

Table 14. STL_SCH_InitFlash output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_OK Function successfully executed STL_NOT_TESTED - FLASH_INIT

Possible source of defensive
programming error: Value must not be
STL_KO Not relevant No state change
• pSingleTmStatus = NULL used
• STL internal data corrupted

UM3191 - Rev 2 page 31/63

 UM3191
STL: User APIs and state machines

7.2.3.2 STL_SCH_ConfigureFlash
Description: configures the flash memory test.
Declaration: STL_Status_t STL_SCH_ConfigureFlash(STL_TmStatus_t *pSingleTmStatus,
STL_MemConfig_t *pFlashConfig)

Table 15. STL_SCH_ConfigureFlash input information

Parameter
Allowed states
Value Comments

*pSingleTmStatus See Caution

Pointer to the flash memory configuration. See Caution.

Field Comments
• Pointer to flash memory subset. See
Caution
• A section cannot overlap with the CRC
area
Field Comments
• Start subset address
in bytes
• Cannot be lower
StartAddr than ROM_START
and higher than
CRC_START
address
*pSubset • End subset address
FLASH_INIT in bytes
*pFlashConfig • Cannot be lower
than ROM_START
EndAddr and higher than
CRC_START
address
• Needs to be higher
than StartAddr

• Pointer to next flash

memory subset. See
*pNext Caution
• Must be set to NULL
for the last subset
• Number of flash memory sections to be
tested during an atomic test
• Set to 1, as minimum (one section per
NumSectionsAtomic test)
• If the value is higher than the number of
sections in all subsets, all flash memory
subsets are tested in one pass

UM3191 - Rev 2 page 32/63

 UM3191
STL: User APIs and state machines

Table 16. STL_SCH_ConfigureFlash output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_NOT_TESTED - FLASH_CONFIGURED
Possible source of
defensive programming
error:
STL_OK Function successfully executed • State not allowed
STL_ERROR No state change
• Wrong configuration
detected
• STL internal data
corrupted
Possible source of defensive
programming error:
STL_KO • pSingleTmStatus = NULL Not relevant Value must not be used No state change
• pFlashConfig = NULL
• STL internal data corrupted

Additional information: in the case of a return value set to STL_KO or *pSingleTmStatus set to STL_ERROR,
the flash memory configuration is not applied.

7.2.3.3 STL_SCH_RunFlashTM
Description: runs flash memory test.
Declaration: STL_Status_t STL_SCH_RunFlashTM(STL_TmStatus_t *pSingleTmStatus)

Table 17. STL_SCH_RunFlashTM input information

Parameters
Allowed states
Value Comments

FLASH_CONFIGURED *pSingleTmStatus See Caution

UM3191 - Rev 2 page 33/63

 UM3191
STL: User APIs and state machines

Table 18. STL_SCH_RunFlashTM output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_PASSED - FLASH_CONFIGURED
STL_PARTIAL_PASSED - FLASH_CONFIGURED
STL_FAILED - FLASH_CONFIGURED
All subsets are already
STL_NOT_TESTED FLASH_CONFIGURED
tested
STL_OK Function successfully executed Possible source of
defensive programming
error:
• State not allowed
STL_ERROR No state change
• Configuration
corrupted
• STL internal data
corrupted
Possible source of defensive
programming error:
STL_KO • pSingleTmStatus = Not relevant Value must not be used No state change
NULL
• STL internal data corrupted

7.2.3.4 STL_SCH_ResetFlash
Description: resets flash memory test.
Declaration: STL_Status_t STL_SCH_ResetFlash(STL_TmStatus_t *pSingleTmStatus)

Table 19. STL_SCH_ResetFlash input information

Parameters
Allowed states
Value Comments

FLASH_CONFIGURED *pSingleTmStatus See Caution

Table 20. STL_SCH_ResetFlash output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

Configuration successfully
STL_NOT_TESTED FLASH_CONFIGURED
applied
Possible source of
defensive programming
error:
STL_OK Function successfully executed
• State not allowed
STL_ERROR No state change
• Configuration
corrupted
• STL internal data
corrupted
Possible source of defensive
programming error:
STL_KO Not relevant Value must not be used No state change
• pSingleTmStatus = NULL
• STL internal data corrupted

Additional information

UM3191 - Rev 2 page 34/63

 UM3191
STL: User APIs and state machines

• Once all subsets are tested, the user needs to reset the test module to perform the flash memory test
again.
• In the case of a return value set to STL_KO or *pSingleTmStatus set to STL_ERROR, the flash
memory reset is not applied.

7.2.3.5 STL_SCH_DeInitFlash
Description: deinitializes flash memory test.
Declaration: STL_Status_t STL_SCH_DeInitFlash(STL_TmStatus_t *pSingleTmStatus)

Table 21. STL_SCH_DeInitFlash input information

Parameters
Allowed states
Value Comments

FLASH_IDLE
FLASH_INIT *pSingleTmStatus See Caution
FLASH_CONFIGURED

Table 22. STL_SCH_DeInitFlash output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_OK Function successfully executed STL_NOT_TESTED - FLASH_IDLE

Possible source of defensive
programming error: Value must not be
STL_KO Not relevant No state change
• pSingleTmStatus = NULL used
• STL internal data corrupted

7.2.4 RAM testing APIs

7.2.4.1 STL_SCH_InitRam
Description: initializes the RAM test.
Declaration: STL_Status_t STL_SCH_InitRam(STL_TmStatus_t *pSingleTmStatus).

Table 23. STL_SCH_InitRam input information

Parameters
Allowed states
Value Comments

RAM_IDLE
RAM_INIT *pSingleTmStatus See Caution
RAM_CONFIGURED

Table 24. STL_SCH_InitRam output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_OK Function successfully executed STL_NOT_TESTED - RAM_INIT

Possible source of defensive
programming error: Value must not be
STL_KO Not relevant No state change
• pSingleTmStatus = NULL used
• STL internal data corrupted

UM3191 - Rev 2 page 35/63

 UM3191
STL: User APIs and state machines

7.2.4.2 STL_Status_t STL_SCH_ConfigureRam

Description: Description: configures the RAM test.
Declaration: STL_Status_t STL_SCH_ConfigureRam(STL_TmStatus_t *pSingleTmStatus,
STL_MemConfig_t *pRamConfig)

Table 25. STL_SCH_ConfigureRam input information

Parameter
Allowed states
Value Comments

*pSingleTmStatus See Caution

This pointer contains the RAM configuration. See Caution
Field Comments
• Pointer to RAM subset. See Caution
• A subset cannot overlap with the RAM
backup buffer if defined
Field Comments
• Start subset address in
bytes
• Start address must be 32-
bit aligned
StartAddr • RAM subset must be
inside RAM area
• Cannot be lower than
RAM_START and higher
than RAM_END address
*pSubset • End subset address in
RAM_INIT bytes
*pRamConfig • Higher than StartAddr
• Cannot be lower than
RAM_START and higher
EndAddr than RAM_END address
• Subset size (EndAddr–
StartAddr) needs to be
multiple of 2 *
RAM_BLOCK_SIZE, 32
bytes
• Pointer to next RAM
subset. See Caution
*pNext
• Must be set to NULL for
the last subset
• Number of RAM sections to be tested during
an atomic test
• Set to 1, as minimum (one section per test)
NumSectionsAtomic
• If the value is higher than the number of
sections in all subsets, all RAM subsets are
tested in one pass

UM3191 - Rev 2 page 36/63

 UM3191
STL: User APIs and state machines

Table 26. STL_SCH_ConfigureRam output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_NOT_TESTED - RAM_CONFIGURED
Possible source of
defensive
programming error:
• State not
STL_OK Function successfully executed allowed
STL_ERROR No state change
• Wrong
configuration
detected
• STL internal
data corrupted
Possible source of defensive
programming error:
Value must not be
STL_KO • pSingleTmStatus = NULL Not relevant No state change
used
• pRamConfig = NULL
• STL internal data corrupted

Additional information: in the case of a return value set to STL_KO or *pSingleTmStatus set to STL_ERROR,
the RAM configuration is not applied.

7.2.4.3 STL_SCH_RunRamTM
Description: runs the RAM test.
Declaration: STL_Status_t STL_SCH_RunRamTM(STL_TmStatus_t *pSingleTmStatus)

Table 27. STL_SCH_RunRamTM input information

Parameters
Allowed states
Value Comments

RAM_CONFIGURED *pSingleTmStatus See Caution

UM3191 - Rev 2 page 37/63

 UM3191
STL: User APIs and state machines

Table 28. STL_SCH_RunRamTM output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_PASSED - RAM_CONFIGURED
STL_PARTIAL_PASS
- RAM_CONFIGURED
ED
STL_FAILED - RAM_CONFIGURED
All subsets are
STL_NOT_TESTED RAM_CONFIGURED
already tested
STL_OK Function successfully executed Possible source of
defensive
programming error:
• State not
STL_ERROR allowed No state change
• Configuration
corrupted
• STL internal
data corrupted
Possible source of defensive
programming error: Value must not be
STL_KO Not relevant No state change
• pSingleTmStatus = NULL used
• STL internal data corrupted

7.2.4.4 STL_Status_t STL_SCH_ResetRam

Description: resets the RAM test.
Declaration: STL_Status_t STL_SCH_ResetRam(STL_TmStatus_t *pSingleTmStatus)

Table 29. STL_SCH_ResetRam input information

Parameters
Allowed states
Value Comments

RAM_CONFIGURED *pSingleTmStatus See Caution

Table 30. STL_SCH_ResetRam output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

Configuration
STL_NOT_TESTED RAM_CONFIGURED
successfully applied
Possible source of
defensive
programming error:
STL_OK Function successfully executed • State not
STL_ERROR allowed No state change
• Configuration
corrupted
• STL internal
data corrupted
Possible source of defensive
programming error: Value must not be
STL_KO Not relevant No state change
• pSingleTmStatus = NULL used
• STL internal data corrupted

UM3191 - Rev 2 page 38/63

 UM3191
STL: User APIs and state machines

Additional information
• Once all subsets are tested, the user needs to reset the test module to perform the RAM test again.
• In the case of a return value set to STL_KO or *pSingleTmStatus set to STL_ERROR, the RAM reset is
not applied.

7.2.4.5 STL_SCH_DeInitRam
Description: deinitializes the RAM test.
Declaration: STL_Status_t STL_SCH_DeInitRam(STL_TmStatus_t *pSingleTmStatus)

Table 31. STL_SCH_DeInitRam input information

Parameters
Allowed states
Value Comments

RAM_IDLE
RAM_INIT *pSingleTmStatus See Caution
RAM_CONFIGURED

Table 32. STL_SCH_DeInitRam output information

STL_Status_t return value *pSingleTmStatus output

Returned state
Value Comments Value Comments

STL_OK Function successfully executed STL_NOT_TESTED - RAM_IDLE

Possible source of defensive
programming error: Value must not be
STL_KO Not relevant No state change
• pSingleTmStatus = NULL used
• STL internal data corrupted

7.2.5 Artificial-failing APIs

7.2.5.1 STL_SCH_StartArtifFailing
Description: sets artificial-failing configuration and starts artificial-failing feature.
Declaration: STL_Status_t STL_SCH_StartArtifFailing(const STL_ArtifFailingConfig_t
*pArtifFailingConfig)

Table 33. STL_SCH_StartArtifFailing input information

Parameters
Allowed states
Value Comments

CPU TMx:
• CPU_TMx_CONFIGURED
Flash TM:
• FLASH_IDLE
• FLASH_INIT *pArtifFailingConfig No state change
• FLASH_CONFIGURED
RAM TM
• RAM_IDLE
• RAM_INIT
• RAM_CONFIGURED

UM3191 - Rev 2 page 39/63

 UM3191
STL: User APIs and state machines

Table 34. STL_SCH_StartArtifFailing output information

STL_Status_t
Comments Output Comments
return value

STL_OK Function successfully executed

Possible source of defensive programming error:
• pArtifFailingConfig = NULL No output parameter No state change
STL_KO • configured values are not set for each test
module
• STL internal data corrupted

Additional information: All the following API calls are executed normally except if the STL_Status_t return value is
set to STL_OK, the test module status (*pSingleTmStatus, *pTmListStatus) is forced to a configured value.

7.2.5.2 STL_SCH_StopArtifFailing
Description: stops the artificial-failing feature.
Declaration: STL_Status_t STL_SCH_StopArtifFailing(void)

Table 35. STL_SCH_StopArtifFailing input information

Parameters
Allowed states
Value Comments

CPU TMx:
• CPU_TMx_CONFIGURED
Flash TM:
• FLASH_IDLE
• FLASH_INIT
No input parameter No state change
• FLASH_CONFIGURED
RAM TM
• RAM_IDLE
• RAM_INIT
• RAM_CONFIGURED

Table 36. STL_SCH_StopArtifFailing output information

STL_Status_t return value Comments Output Comments

STL_OK Function successfully executed

Possible source of defensive No output
No state change
STL_KO programming error: parameter
• STL internal data corrupted

7.3 State machines

Each CPU test module has its own state machine diagram linked to the CPU test APIs.

UM3191 - Rev 2 page 40/63

 UM3191
STL: User APIs and state machines

CPU test APIs

Figure 11. State machine diagram - CPU test APIs

STL_SCH_Init()

SCH_IDLE
STL_SCH_Init()

CPU_TMx_C
ONFIGURED
SW reset

Return of STL_SCH_RunCpuTMx()

STL_SCH_RunCpuTMx()
CPU_TMx_
RUNNING

DT69947V1

UM3191 - Rev 2 page 41/63

 UM3191
STL: User APIs and state machines

Flash memory test APIs

Figure 12. State machine diagram - flash memory test APIs

STL_SCH_DeInitFlash()
STL_SCH_Init() STL_SCH_InitFlash()
STL_SCH_Init()

STL_SCH_InitFlash()
FLASH_IDLE STL_SCH_ConfigureFlash()
STL_SCH_Init() FLASH_INIT

STL_SCH_DeInitFlash()

STL_SCH_InitFlash()
SCH_IDLE
STL_SCH_ResetFlash()(1)

STL_SCH_DeInitFlash() FLASH_
CONFIGURED

STL_SCH_Init()

Return of STL_SCH_RunFlashTM()

SW reset

STL_SCH_RunFlashTM()
FLASH_R
UNNING

DT69948V1
Note (1): Once all subsets are tested, the user needs to reset the flash memory test module to perform the test again.

UM3191 - Rev 2 page 42/63

 UM3191
STL: User APIs and state machines

RAM test APIs

Figure 13. State machine diagram - RAM test APIs

STL_SCH_DeInitRam()
STL_SCH_Init() STL_SCH_InitRam()
STL_SCH_Init()

STL_SCH_InitRam()
RAM_IDLE STL_SCH_ConfigureRam()
STL_SCH_Init() RAM_INIT

STL_SCH_DeInitRam()

STL_SCH_InitRam()
SCH_IDLE

STL_SCH_DeInitRam() RAM_
CONFIGURED
STL_SCH_Init()
STL_SCH_ResetRam()(1)

Return of STL_SCH_RunRamTM()

SW reset

STL_SCH_RunRamTM()
RAM_
RUNNING

DT69949V1
Note (1): Once all subsets are tested, the user needs to reset the RAM test module to perform the test again.

7.4 API usage and sequencing

The user application must:
• Maintain the availability and integrity of pointers passed as parameters during the tests. The STL does not
copy the pointer content, and accesses directly the memory addresses defined by the application.
• Check the status of function return value (STL_Status_t), before checking the test result
(STL_TmStatus_t or STL_TmListStatus_t). See the example in the delivered applications.
The APIs run independently of each other and therefore can be called in any order.
Only APIs dedicated to the configuration and initialization of the memories tests must be called before any
execution of these tests is applied. See Section 7.3: State machines for more details.
The test flow is simplified, all the tests are now executed from C-code. All the modules are common and suitable
for both startup and runtime testing. Differentiation between startup and runtime tests can be performed by proper
sequencing and configuration of test modules. After application reset, common practice is to perform a full initial
sequence including the complete set of tests executed over all the memory areas before the application starts.
This sequence is defined in following order:
1. All the CPU tests
2. Complete tests of nonvolatile memory integrity
3. Functional test overall for the available space of volatile memories including the area especially dedicated to
the stack
Note: Temporarily suppressing of the memory content backup can be applied to speed up initial testing of huge
RAM areas where user does not need to preserve the memory content during this test. For more details see
Section 4.3.8: RAM backup buffer. Functional test is not executed over areas containing program code and
data when the code is executed from RAM.
4. Specific customer tests

UM3191 - Rev 2 page 43/63

 UM3191
STL: User APIs and state machines

Later, at runtime, the order of the tests can be changed and executed in more relaxed way. The memory regions
under tests can be reduced. The test process can even be dynamically modified with prior focus on those areas
where the most recently executed safety related code and data are stored. This is especially the case when
considering factors like:
• Available application process safety time
• System overall performance
• Concrete status of the application

7.5 User parameters

In addition to parameters set directly inside the APIs, there are few parameters to be customized in the
stl_user_param_template_cm4.c and stl_user_param_template_cm0plus.c files. They are located
in the code, with the following comments:
/* customisable */

Extract from stl_user_param_template_cm4.c:

/* Flash configuration */
#define STL_ROM_START (0x08000000U) /* customizable */
#define STL_ROM_END (0x0801FFFFU) /* customizable */

Extract from stl_user_param_template_cm0plus.c:

/* Flash configuration */
#define STL_ROM_START (0x08020000UL) /* customizable */
#define STL_ROM_END_ADDR (0x0803FFFFUL) /* customizable */

The customization depends upon the STM32 product and the user choice.
/* TM RAM Backup Buffer configuration */
…..
/* User shall locate the buffer in RAM */
/* The RAM backup buffer is placed in "backup_buffer_section". */
/* "backup_buffer_section" section is defined in scatter file */

The customizing depends on the user choice.

The remaining user parameters are defined by flags, and can be checked in the following core associated files:
• stl_user_param_template.cmxxx.c: use of RAM backup buffer or not
• stl_util.cmxxx.c: use of software or hardware CRC computation
• stl_stm32_hw_config.cmxxx.h: if CRC hardware is used, choose the right CRC IP configuration
according to the STM32 device
Refer to Section 5.5.2: Steps to build an application from scratch for the flag configuration check.

UM3191 - Rev 2 page 44/63

 UM3191
Test examples

8 Test examples

Figure 14 shows an example of a possible sequence of STL API calls through the STL scheduler and returned
information provided by STL (refer to Figure 1 and Table 2).

Figure 14. Test flow example

User STL_SCH
STL_SCH_Init

STL_OK

STL_SCH_InitFlash (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
STL_SCH_InitRam (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
STL_SCH_ConfigureFlash (*p_SingleTmStatus, *pFlashConfig)
*pFlashConfig: Flash memory subsets tested in one shot

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
STL_SCH_ConfigureRam (*p_SingleTmStatus, *pRamConfig)
*pRamConfig: RAMsubsets tested in two shots

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
STL_SCH_RunCpuTM1L (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_ PASSED
STL_SCH_RunCpuTMCB (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_ PASSED
STL_RunFlashTM (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_PASSED
STL_SCH_RunRamTM (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_PARTIAL_PASSED
STL_SCH_RunRamTM (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_PASSED
STL_SCH_InitFlash (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
STL_SCH_InitRam (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
STL_SCH_DeInitFlash (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
STL_SCH_DeInitRam (*p_SingleTmStatus)

STL_OK
pSingleTmStatus =
STL_NOT_TESTED
DT70600V1

Legend:
Test status

UM3191 - Rev 2 page 45/63

 UM3191
Test examples

Figure 15 shows a detailed example of flash memory test flow handling:

• Use of two flash memory subsets
• Use of functions
– STL_SCH_RunFlashTM → only the flash memory test module is executed
– STL_SCH_ResetFlash
• Function return value
• Flash memory test module result value: pSingleTmStatus → in this case, it contains the result of the
flash memory test
Figure 16 shows a detailed example of RAM test flow handling:
• Use of two RAM subsets
• Use of functions:
– STL_SCH_RunRAMTM → only the RAM test module is executed
– STL_SCH_ResetRam
• Function return value
• RAM test module result value: pSingleTmStatus → in this case, it contains the result of the RAM
memory test

UM3191 - Rev 2 page 46/63

page 47/63 UM3191 - Rev 2

STL
User
Init STL

Init and configure flash memory

STL_SCH_RunFlashTM
(*pSingleTmStatus)
Main scheduler

Flash tests module

Main scheduler STL_OK

...

STL_SCH_RunFlashTM
*pSingleTmStatus =

(*pSingleTmStatus)
STL_PARTIAL_PASSED

Main scheduler

Flash tests module

Main scheduler STL_OK

K sections

...
...

STL_SCH_RunFlashTM

First subset
*pSingleTmStatus =

K sections (*pSingleTmStatus)
STL_PARTIAL_PASSED

Main scheduler
Flash tests module
STL_OK

...
Main scheduler
...

STL_SCH_RunFlashTM
*pSingleTmStatus =

(*pSingleTmStatus)
Main scheduler
STL_PARTIAL_PASSED

K sections
... Flash tests module

Main scheduler STL_OK

K sections

Last subset
...

K sections STL_SCH_RunFlashTM
*pSingleTmStatus =

(*pSingleTmStatus)
Main scheduler
STL_PARTIAL_PASSED

Flash tests module

Main scheduler STL_OK
Figure 15. Flash memory test flow example

...

STL_SCH_RunFlashTM
= STL_PASSED

(*pSingleTmStatus)
*pSingleTmStatus

Main scheduler

Flash tests module

Main scheduler STL_OK
memory
Flash
...

STL_SCH_ResetFlash
(*pSingleTmStatus)
*pSingleTmStatus =
STL_NOT_TESTED

Main scheduler

Flash tests module

Main scheduler STL_OK

...

STL_SCH_RunFlashTM
(*pSingleTmStatus)
Legend:

Main scheduler
*pSingleTmStatus =
STL_NOT_TESTED

Test status

Flash tests module

Main scheduler

Main scheduler STL_OK

Flash tests module
*pSingleTmStatus =
STL_PARTIAL_PASSED

Test examples
UM3191
page 48/63 UM3191 - Rev 2

STL
User
Init STL

Init and configure RAM

STL_SCH_RunRamTM
(*pSingleTmStatus)
Main scheduler

RAM tests module

Main scheduler STL_OK

...

STL_SCH_RunRamTM
*pSingleTmStatus =

(*pSingleTmStatus)
STL_PARTIAL_PASSED

Main scheduler

RAM tests module

Main scheduler STL_OK

N sections

...
...

STL_SCH_RunRamTM

First subset
*pSingleTmStatus =

N sections (*pSingleTmStatus)
STL_PARTIAL_PASSED

Main scheduler
RAM tests module
STL_OK

...
Main scheduler
...

STL_SCH_RunRamTM
*pSingleTmStatus =

(*pSingleTmStatus)
Main scheduler
STL_PARTIAL_PASSED

N sections
RAM tests module
...

Main scheduler STL_OK

N sections
Last subset
...

N sections STL_SCH_RunRamTM
*pSingleTmStatus =

(*pSingleTmStatus)
Main scheduler
STL_PARTIAL_PASSED
Figure 16. RAM test flow example

RAM tests module

Main scheduler STL_OK
...

STL_SCH_RunRamTM
= STL_PASSED

(*pSingleTmStatus)
*pSingleTmStatus

Main scheduler

RAM tests module

Main Scheduler STL_OK
RAM
...

STL_SCH_ResetRam
(*pSingleTmStatus)
*pSingleTmStatus =
STL_NOT_TESTED

Main scheduler

RAM tests module

Main scheduler STL_OK

...

STL_SCH_RunRamTM
Legend:

(*pSingleTmStatus)
Test status

Main scheduler
*pSingleTmStatus =
STL_NOT_TESTED

RAM tests module

Main scheduler
RAM tests module

Main scheduler STL_OK

*pSingleTmStatus =
STL_PARTIAL_PASSED

Test examples
UM3191
 UM3191
STL: execution timing details

9 STL: execution timing details

The data in the following table is obtained with the test set-up described in Section 4.2: STL performance data

Table 37. Cortex®-M0+ integration tests

Duration (in μs)

Test Tested memory
Hardware CRC Software CRC

STL_SCH_InitFlash 11 11 -
STL_SCH_ConfigureFlash 17 17 -
STL_SCH_RunFlashTM 1016 7641 17408 bytes tested
STL_SCH_InitRam 11 11 -
STL_SCH_ConfigureRam 19 19 -
STL_SCH_RunRamTM 37521 37521 32768 bytes tested
STL_SCH_RunCpuTM1L 113 113 -
STL_SCH_RunCpuTM7 42 42 -
STL_SCH_RunCpuTMCB 15 15 -

Table 38. Cortex®-M4 integration tests

Duration (in μs)

Test Tested memory
Hardware CRC Software CRC

STL_SCH_InitFlash 9 9 -
STL_SCH_ConfigureFlash 14 14 -
STL_SCH_RunFlashTM 807 5658 17408 bytes tested
STL_SCH_InitRam 9 9 -
STL_SCH_ConfigureRam 14 14 -
STL_SCH_RunRamTM 28999 29042 32768 bytes tested
STL_SCH_RunCpuTM1L 78 80 -
STL_SCH_RunCpuTM7 35 35 -
STL_SCH_RunCpuTMCB 14 14 -

UM3191 - Rev 2 page 49/63

 UM3191
Application-specific tests not included in ST firmware self-test library

10 Application-specific tests not included in ST firmware self-test

library

The user must focus on all the remaining required tests covering application specific MCU parts not included in
the ST firmware library:
• Test of analog parts (ADC/DAC, multiplexer)
• Test of digital I/O
• External addressing
• External communication
• Timing and interrupts
• System clock frequency measurement.
Note: The clock frequency measurement is not an integrated part of the STL package. The clock testing module
is provided as full source format within STL integration example to demonstrate the capability of
implementing additional user defined testing modules which can be included at the STL flow. For more
details refer to Section 10.5: Extension capabilities STL library.
A valid solution for these components is strongly dependent on application and device-peripheral capability. The
application must follow as precisely as possible the suggested testing principles from the very early stages of its
design.
Very often this method leads to redundancy at both hardware and software levels.
Hardware methods can be based on:
• Multiplication of inputs and/or outputs
• Reference point measurement
• Loop-back read control at analog or digital outputs such as DAC, PWM, GPIO
• Configuration protection.
Software methods can be based on:
• Repetition in time, multiple acquisitions, multiple checks, decisions, or calculations made at different times
or performed by different methods
• Data redundancy (data copies, parity check, error correction/detection codes, checksum, protocol)
• Plausibility check (valid range, valid combination, expected change, or trend)
• Periodicity and occurrence checks (flow and occurrence in time controls)
• Periodic checks of correct configuration (for example, read back the configuration registers).

10.1 Analog signals

Measured values must be checked for consistency and verified by measurements performed on other redundant
channels. Free channels can be used for reading some reference voltages with testing of analog multiplexers
used in the application. The internal reference voltage must also be checked.
Some STM32 microcontroller devices feature two (or even three) independent ADC blocks. To ensure the
reliability of the results, perform several conversions on the same channel using two different ADC blocks for
security reasons. The results can be obtained using either:
• Multiple acquisitions from one channel
• Compare redundant channels followed by an averaging operation.
Here are some tips for testing the functionality of analog parts at STM32 microcontroller devices.

UM3191 - Rev 2 page 50/63

 UM3191
Application-specific tests not included in ST firmware self-test library

ADC input pin disconnection

The ADC input pin disconnection can be tested by applying additional signal source on the tested pin.
• Some STM32 microcontroller devices feature internal pull-down or pull-up resistor activation facilities on
the analog input. They can also feature a free pin with DAC functionality or a digital GPIO output. Any one
of these pins can be used as a known reference input to the ADC.
• Some STM32 microcontroller devices feature a routing interface. This interface can be used for internal
connection between pins to make:
– testing loop-back
– additional signal injection
– duplicate measurement at some other independent channel.
Note: The user must prevent any critical voltage injection into an analog pin. This can happen when digital and analog
signals are combined and different power levels are applied to analog and digital parts (VDD > VDDA).

Internal reference voltage and temperature sensor (VBAT for some devices)

• Ratio between these signals can be verified within the allowed ranges.
• Additional testing can be performed where the VDD voltage is known.

ADC clock
Measurement of the ADC conversion time (by timers) can be used to test the independent ADC clock
functionality.

DAC output functionality

Free ADC channels can be used to check if the DAC output channel is working correctly.
The routing interface can be used when connecting the ADC input channel and the DAC output channel.

Comparator functionality
Comparison between known voltage and DAC output or internal reference voltage can be used for testing
comparator output on another comparator input.
Analog signal disconnection can be tested by pull-down or pull-up activation on a tested pin and comparing this
signal with the DAC voltage as reference on another comparator input.

Operational amplifier
Functionality can be tested forcing (or measuring) a known analog signal to the operational amplifier (OPAMP)
input pin, and internally measuring the output voltage with the ADC. The input signal to the OPAMP can be also
measured by ADC (on another channel).

10.2 Digital I/Os

Class B tests must detect any malfunction on digital I/Os, too. It could be covered by plausibility checks together
with some other application parts. For example, change of an analog signal from the temperature sensor must be
checked when heating/cooling digital control is switched on/off. Selected port bits can be locked by applying the
correct lock sequence to the lock bit in the GPIOx_LCKR register. This action prevents unexpected changes to
the port configuration. Reconfiguration is only possible at the next reset sequence in this case. In addition, the bit
banding feature can be used for atomic manipulation of the SRAM and peripheral registers.

10.3 Interrupts
Occurrence in time and periodicity of events must be checked. Different methods can be used; one of them uses
a set of incremental counters where every interrupt event increments a specific counter. The values in the
counters are then cross-checked periodically with other independent time bases. The number of events occurred
within the last period depends upon the application requirements.
The configuration lock feature can be used to secure the timer register settings with three levels controlled by the
TIMx_BDTR register. Unused interrupt vectors must be diverted into a common error handler. Polling is preferable
for non-safety relevant tasks if possible to simplify an application interrupt scheme.

UM3191 - Rev 2 page 51/63

 UM3191
Application-specific tests not included in ST firmware self-test library

10.4 Communication
Data exchange during communication sessions must be checked while including redundant information in the
data packets. Parity, sync signals, CRC check sums, block repetition, or protocol numbering can be used for this
purpose. Robust application software protocol stacks like TCP/IP give higher level of protection, if necessary.
Periodicity and occurrence in time of the communication events together with protocol error signals has to be
checked permanently.
The user can find more information and methods in product-dedicated safety manuals.

10.5 Extension capabilities STL library

This framework version features a significantly easier and more flexible implementation than the previous
versions of this STL library (see Section 1.2: Reference documents) which allows for an easier extension. Even
with the new applied format, the framework keeps the same set of self-testing methods to comply with the IEC
60730 standard which are already implemented by previous versions of the library:
• Test of registers at CPU TMs
• 32-bit CRC calculation compatible with STM32 HW CRC unit at Flash TM
• March C test respecting physical address order of the RAM TM
• Timer triggered by LSI to check system clock frequency of the clock TM defined at STL integration example
The main improvements of the new framework version are:
• Module oriented
• Supports partial testing
• Based on configuration and parametrizing structures
• No differentiation between startup and runtime test modules
• CRC calculation support based on a format provided by the STM32CubeProgrammer command-line
feature
• Pre-compiled and fixed object code format of key generic modules
• No dependency of the generic modules execution on drivers or compilers
• Error handling includes reporting of defensive programing results
• Artificial failure control feature to verify the proper integration of the modules with no need for additional
instrumentation code
• Easy extension by additional application specific modules.
An example of an additional specific test module implementation is available in the firmware package integration
example. A specific test module based on the cross check measurement method of two independent clock
sources is delivered as open source format together with the firmware package integration example. This module
must be adapted by the end user to take into account specific dependencies on the configuration of the applied
clock system.
This module uses the same measurement principle already applied in previous versions of the library. The
hardware used for the frequency comparison must initially be configured (Channel 1 of TIM16 triggered by LSI) to
invoke clock measurement before the associated API is called. This hardware configuration is done at the end of
STL_Init() procedure in the main.c file. The API is written to use interface compatibility with the regular APIs
integrated in the STL so the same format is applied in its declaration:
STL_Status_t STL_SCH_RunClockTest(STL_TmStatus_t *pSingleTmStatus)

The parameter that is passed during this function call acts as a pointer to the clock module measurement status,
and the function itself provides a STL_KO vs STL_OK return status as well as do the regular STL modules if
defensive programing fails. If the clock measurement hardware is active and the new period value updated by the
last measurement cycle (set to 8 consecutive LSI periods) is found at the expected interval (defined by macros
CLK_LimitLow and CLK_LimitHigh), the module measurement status value is changed into STL_PASSED. If
not it is set to STL_FAILED as per the regular API modules. This is also the case when artificial failing of the
module is invoked.
In a similar way, the user can integrate the following modules. For example, any stack hardening techniques like
stack boundary area check or implementing watchdog testing and servicing is no longer included at this new
package by default. The source code of these tests is available in older versions of this library see [2]. Refer to [1]
for additional information about the commonly recognized safety methods that are not specifically required by the
household standard. They may be useful to improve the user application robustness.

UM3191 - Rev 2 page 52/63

 UM3191
Application-specific tests not included in ST firmware self-test library

Dual-core information
The integration example provides full source code of additional support of communication and synchronization
between STLs running in parallel on two embedded cores, too. The provided solution fully corresponds to the one
applied at previous versions of the library (for more details see [2]). The two cores communicate via embedded
hardware semaphore system unit (HSEM) to cross check each other activity and testing status. Both cores
monitor HSEM events by interrupts and process occupancy checks of three dedicated channels to see the STL
correct ongoing status reciprocally. The implemented checks prevent potential HW CRC unit resource conflict
during parallel initialization of both the STLs, too (refer to STL_SCH_Init function call in Section 4.3.4: CRC
resources).

UM3191 - Rev 2 page 53/63

 UM3191
Compliance with IEC, UL, and CSA standards

11 Compliance with IEC, UL, and CSA standards

The pivotal IEC standards are IEC 60730-1 and IEC 60335-1, harmonized with UL/CSA 60730-1 and UL/CSA
60335-1 starting from the 4th edition. Previous UL/CSA editions use references to the UL1998 standard in
addition.
The standards are updated at regular intervals. The range of all the regulations collected in the standards is very
large; the sections that concern the requirements for software self-tests of generic parts of microcontrollers is very
specific. In most cases, the provided updates do not impact these specific parts of the standard at all. Therefore,
an obsolete certification can still comply and stay valid for newer editions of the standard.
The relevant detailed conditions required are defined in:
• Annexes Q and R of the IEC 60335-1 norm
• Annex H of the IEC 60730-1 norm.
Three classes are defined by the IEC 60730-1:2010 H.2.22 they are:
• Class A: control functions that are not intended to be relied upon for the safety of the application.
• Class B: control functions that are intended to prevent an unsafe state of the controlled equipment. Failure
of the control function does not directly lead to a hazardous situation.
• Class C: control functions that are intended to prevent special hazards such as explosion or which failure
could directly cause a hazard in the appliance.
For a programmable electronic component applying a safety protection function, the IEC 60335-1 standard
requires incorporation of software measures to control fault and error conditions specified in tables R.1 and R.2:
• Table R.1 summarizes general conditions comparable with requirements given for Class B level
• Table R.2 summarizes specific conditions comparable with requirements given for Class C level.
Requirements for Class B level software, which is the subject of this user manual, are defined to prevent hazards
if another fault occurs elsewhere in the appliance. In this case, the self-test software is run on the appliance after
a failure. An accidental software fault occurring during a safety-critical routine execution does not necessarily
result in a hazard due to another applied redundant software procedure or hardware protection function required
at this level.
There is no such hardware protection required in Class C level counting that whatever fault at safety-critical
software can result in a potential hazard. To comply with this level, more robust testing is required than the one
usually applicable to standard industrial microcontrollers like the STM32. An acceptable solution usually leads to
the implementation of specific hardware redundancy at system level, like dual channel structures.
For more information on more stringent test methods, refer to the industrial documentation [1].
IEC 60730-1 defines the set of applicable architectures acceptable for the design of Class B control functions:
• Single channel with functional test. A single CPU executes the software control functions as required. A
functional test is performed as the software starts. It guarantees that all critical features work properly.
• Single channel with periodic self-test. A single CPU executes the software control functions. Embedded
periodic tests check the various critical functions of the system without impacting the performance of the
planned control tasks.
• Dual channel (homogeneous or diverse) with comparison. The software is designed to execute control
functions (identically or differently) on two independent CPUs. Both CPUs compare internal signals for fault
detection when executing any safety-critical task.
Note: This structure is recognized to comply with Class C level also. A common principle is that whatever
method complies with Class C automatically complies with Class B.
An overview of the methods applied by STL and their references to the standards are listed on the table below.
The STL is focused on generic components of the microcontroller reused at all applications. The test of the other
parts is under the end-user responsibility as their testing is mostly application specific and can be achieved
effectively at the planning stage of the system design. Refer to Section 10: Application-specific tests not included
in ST firmware self-test library for more information on how to handle these application-specific tests.

UM3191 - Rev 2 page 54/63

 UM3191
Compliance with IEC, UL, and CSA standards

Table 39. IEC 60335-1 components covered by the X-CUBE-CLASSB library by methods recognized by IEC-60730-1

References to
Component of Table R.1 (IEC Safety method applied
Class B IEC 60730-1: Fault/error Note
60335-1: Annex R) at X-CUBE-CLASSB
Annex H)

Combination of functional and

pattern tests of the CPU
H.2.16.5
Periodic run of the STL registers,(general-purpose R0-
1.1 CPU registers X H.2.16.6 Stuck at TM1L, TM7, and TMCB R12, special-purpose main and
CPU test modules process stack pointers R13,
H.2.19.6
program status APSR and
CONTROL registers)(1)
1.2 Instruction
decoding and N/A Not required for Class B
1. CPU execution

N/A Logical and time slot program

1.3 Program H.2.18.10.2
X Stuck at End-user responsibility sequence monitoring,
counter H.2.18.10.4
implementation of watchdogs
1.4 Addressing N/A Not required for Class B
1.5 Data path
instruction N/A Not required for Class B
decoding
Handshake of results is
No interrupt
H.2.18.10.4 applied at the interrupt End-user responsibility for the
or too
2. Interrupt handling and execution X associated with a clock other interrupts implemented at
H2.18.18 frequent
cross-check application
interrupts
measurement module
Periodic run of clock
cross-check module.
Clock cross-check measurement
Added at open source
H.2.18.10.1 Wrong done between two independent
3. Clock X format as a user specific
H.2.18.10.4 frequency clock sources (system clock and
test module within the
LSI)
firmware integration
example
H.2.19.3.1
4.1 Invariable All single bit Periodic execution of the ECC enable under end-user
X H.2.19.3.2
memory faults STL FlashTM test module responsibility(2)
H.2.19.8.2

4.2. Variable H.2.19.6 Periodic execution of the ECC or parity enable under end-
X DC fault
memory H.2.19.8.2 STL RamTM test module user responsibility(2)
4. Memory
4.3 Addressing
(relevant for
variable and X H.2.19.8.2 Stuck at - Tested indirectly by execution of
invariable the applied memory test
memory) modules

5.1 Data X H.2.19.8.2 Stuck at - ECC enable under end-user

5. Internal responsibility(2)
data path Wrong
5.2 Addressing X H.2.19.8.2 -
address
N/A
6. External communication X - - -
End-user responsibility
N/A
7. I/O periphery X - - -
End-user responsibility
8. Monitoring devices and
N/A Not required for Class B
comparators
9. Custom chips X - - N/A -

1. CPU registers R14 (LR) and R15 (PC) are tested indirectly via defensive programming methods. Version V4.0.1 extends the APSR testing
by stuck at test of the GE bit field.
2. For availability and functionality of concrete embedded hardware safety feature, refer to the product user and safety manual.

UM3191 - Rev 2 page 55/63

 UM3191

Revision history
Table 40. Document revision history

Date Version Changes

03-Aug-2023 1 Initial release.

Updated:
• Section 4.2.1: STL execution timings
03-Feb-2025 2
• Section 4.2.2: STL code and data size
• Section 9: STL: execution timing details

UM3191 - Rev 2 page 56/63

 UM3191
Glossary

Glossary

ADC analog to digital converter SDK software development kit

AEABI Arm® embedded application binary interface STL self-test library

API application programing interface TM test module

APSR CPU status register

BSP board support package

Class B
middle level of regulations targeting safety for home
appliances (UL/CSA/IEC 60730-1/60335-1)

CMSIS common microcontroller software interface

standard

CPU central processing unit

CRC cyclic redundancy check

DAC digital to analog conveter

FPU floating-point unit

GPIO general purpose input output

HAL hardware abstraction level

ICache instruction cache

IDE integrated development environment

LL low layer

MCU microcontroller unit

MPU memory protection unit

MSP main stack pointer

OPAMP operational amplifier

PSP process stack pointer

PWM pulse width modulation

RAM random access memory

UM3191 - Rev 2 page 57/63

 UM3191
Contents

Contents
1 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Reference documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 STM32Cube overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 What is STM32Cube?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 How does this software complement STM32Cube? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 STL overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
3.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Supported products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 STL description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
4.1 STL functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1 Scheduler principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2 CPU Arm® core tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.3 Flash memory tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.4 RAM tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 STL performance data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 STL execution timings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 STL code and data size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3 STL stack usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4 STL heap usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.5 STL interrupt masking time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 STL user constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 Dual-core STL constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2 Privileged-level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.3 RCC resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.4 CRC resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.5 Interrupt management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.6 DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.7 Supported memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.8 RAM backup buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.9 Memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.10 Processor mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 End-user integration tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1 Test 1: correct STL execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.2 Test 2: correct STL error-message processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

UM3191 - Rev 2 page 58/63

 UM3191
Contents

5 Package description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

5.1 General description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 STM32Cube HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2 Board support package (BSP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3 STL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.4 User application example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.5 STL integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.1 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.2 Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.3 Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.5 Application: compilation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.5.1 Steps to build a delivered STL example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.5.2 Steps to build an application from scratch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Hardware and software environment setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
6.1 Hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Software setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1 Development tool-chains and compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2 CRC tool set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 STL: User APIs and state machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
7.1 User structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2 User APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.1 Common API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.2 CPU Arm® core testing APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.3 Flash memory testing APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.4 RAM testing APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2.5 Artificial-failing APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3 State machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.4 API usage and sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.5 User parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8 Test examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
9 STL: execution timing details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
10 Application-specific tests not included in ST firmware self-test library . . . . . . . . . . . . .50
10.1 Analog signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

UM3191 - Rev 2 page 59/63

 UM3191
Contents

10.2 Digital I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

10.3 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.5 Extension capabilities STL library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11 Compliance with IEC, UL, and CSA standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
List of figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

UM3191 - Rev 2 page 60/63

 UM3191
List of tables

List of tables
Table 1. Applicable product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table 2. STL return information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 3. Arm®Cortex®-M0+ STL execution timings, clock at 48 MHz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 4. Arm®Cortex®-M4 STL execution timings, clock at 48 MHz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 5. Arm®Cortex®-M0+ STL code size and data size (in bytes). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 6. Arm®Cortex®-M4 STL code size and data size (in bytes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 7. Cortex®-M0+ STL maximum interrupt masking information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 8. Cortex®-M4 STL maximum interrupt masking information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 9. STL_SCH_Init input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Table 10. STL_SCH_Init output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Table 11. STL_SCH_RunCpuTMx input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 12. STL_SCH_RunCpuTMx output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 13. STL_SCH_InitFlash input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 14. STL_SCH_InitFlash output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 15. STL_SCH_ConfigureFlash input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Table 16. STL_SCH_ConfigureFlash output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 17. STL_SCH_RunFlashTM input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 18. STL_SCH_RunFlashTM output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Table 19. STL_SCH_ResetFlash input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Table 20. STL_SCH_ResetFlash output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Table 21. STL_SCH_DeInitFlash input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 22. STL_SCH_DeInitFlash output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 23. STL_SCH_InitRam input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 24. STL_SCH_InitRam output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 25. STL_SCH_ConfigureRam input information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table 26. STL_SCH_ConfigureRam output information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 27. STL_SCH_RunRamTM input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 28. STL_SCH_RunRamTM output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table 29. STL_SCH_ResetRam input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table 30. STL_SCH_ResetRam output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table 31. STL_SCH_DeInitRam input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 32. STL_SCH_DeInitRam output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 33. STL_SCH_StartArtifFailing input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 34. STL_SCH_StartArtifFailing output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Table 35. STL_SCH_StopArtifFailing input information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Table 36. STL_SCH_StopArtifFailing output information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Table 37. Cortex®-M0+ integration tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 38. Cortex®-M4 integration tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 39. IEC 60335-1 components covered by the X-CUBE-CLASSB library by methods recognized by IEC-60730-1 . . . . 55
Table 40. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

UM3191 - Rev 2 page 61/63

 UM3191
List of figures

List of figures
Figure 1. STL architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 2. Single test control call architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 3. Flash memory test: CRC principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 4. Flash memory test: CRC use cases versus program areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 5. RAM test: usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 6. Software architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 7. Project file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 8. IAR™ post-build actions screenshot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 9. CRC tool command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 10. STM32 Nucleo board example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 11. State machine diagram - CPU test APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 12. State machine diagram - flash memory test APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 13. State machine diagram - RAM test APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 14. Test flow example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 15. Flash memory test flow example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 16. RAM test flow example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

UM3191 - Rev 2 page 62/63

 UM3191

IMPORTANT NOTICE – 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, 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, 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.
© 2025 STMicroelectronics – All rights reserved

UM3191 - Rev 2 page 63/63