How it Works
STM
Loading...
AN4435
Application note
71 pgs1.75 Mb0
Table of contents
Loading...

STM AN4435 Application note

AN4435
Application note
Guidelines for obtaining UL/CSA/IEC 60730-1/60335-1
Class B certification in any STM32 application
Introduction
The current safety recommendations and requirements are specified in world wide recognized standards issued by IEC (International Electrotechnical Commission), UL (Underwriters Laboratories) and CSA (Canadian Standards Association) authorities. Compliance, verification and certification are the focus of institutions like TUV and VDE (mostly operating in Europe), UL and CSA (targeting mainly US and Canadian markets).
The main purpose of this application note and of the associated software X-CUBE-CLASSB is to facilitate and accelerate user software development and certification processes for applications based on STM32 32-bit Arm requirements and certifications.
®
Cortex® microcontrollers subject to these
The safety package (self test library, or STL) collects a set of common tests dedicated mainly to generic blocks of STM32 microcontrollers. The STL set is based on the unique STM32Cube interface with specific HAL (hardware abstraction layer) services and drivers published by ST for dedicated STM32 products. Differences are covered by product specific tests and added settings (e.g. CPU core, RAM design, clock control).
The user can include both the STL package and dedicated HAL drivers into a final customer project, together with additional product specific tests and settings. Implementation examples of the STL package are available for specific products of the mainstream STM32F0, STM32F1, STM32F3, STM32G0 and STM32G4, performance STM32F2, STM32F4, STM32F7 and STM32H7, low power STM32L0, STM32L1, STM32L4 and STM32L5 and wireless STM32WB Series. Specific projects (IAR™-EWARM, Keil
®
Arm
and GCC and Eclipse™ based SWSTM32 or STM32CubeIDE environment and
toolchains) are included for each example, built upon a dedicated ST evaluation board.
The common part of STL package can be reused for any other microcontroller of the STM32 family due to the unique Cube interface to the HAL services.
The user has to understand that the STL package is pre-certified for methodology and techniques used. While the provided examples show how to integrate the STL package and the associated FW (HAL drivers) in the application, the final implementation and functionality always has to be verified by the certification body at the application level.
Note: STMicroelectronics develops derivative firmware supporting new products step by step.
Contact your local ST sales office to get support and the latest information about available examples.
®
MDK-
April 2021 AN4435 Rev 9 1/71
www.st.com
1
Contents AN4435
Contents
1 Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Package variation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Main differences between STL packages from product point of view 10
3.1 CPU tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Clock tests and time base interval measurement . . . . . . . . . . . . . . . . . . . 12
3.3 SRAM tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Flash memory integrity tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Specific aspects concerning TrustZone controller . . . . . . . . . . . . . . . . . . 15
3.6 Start-up and system initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 Firmware configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8 Firmware integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.9 HAL driver interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.10 Incompatibility with previous versions of the STL . . . . . . . . . . . . . . . . . . . 20
3.11 Dual core support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Compliance with IEC, UL and CSA standards . . . . . . . . . . . . . . . . . . . 26
4.1 Generic tests included in STL firmware package . . . . . . . . . . . . . . . . . . . 28
4.2 Application specific tests not included in ST firmware self test library . . . 30
4.2.1 Analog signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2 Digital I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.3 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Safety life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Class B software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1 Common software principles used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1 Fail safe mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2 Safety related variables and stack boundary control . . . . . . . . . . . . . . . 34
5.1.3 Flow control procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Tool specific integration of the library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 Projects included in the package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2/71 AN4435 Rev 9
AN4435 Contents
5.2.2 Start-up file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.3 Defining new safety variables and memory areas under check . . . . . . 38
5.2.4 Application implementation examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Execution timing measurement and control . . . . . . . . . . . . . . . . . . . . . . . 40
5.4 Package configuration and debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.1 Configuration control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.2 Verbose diagnostic mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.3 Debugging the package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Class B solution structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1 Integration of the software into the user application . . . . . . . . . . . . . . . . . 49
6.2 Description of start-up self tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.1 CPU start-up self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.2 Watchdog start-up self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Flash memory complete check sum self test . . . . . . . . . . . . . . . . . . . . . 55
6.2.4 Full RAM March-C self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.5 Clock start-up self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.6 Control flow check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Periodic run time self tests initialization . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.4 Description of periodic run time self tests . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.4.1 Run time self tests structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.4.2 CPU light run time self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.3 Stack boundaries runtime test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.4 Clock run time self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.5 Partial Flash CRC run time self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4.6 Watchdog service in run time test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4.7 Partial RAM run time self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Appendix A APIs overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
AN4435 Rev 9 3/71
3
List of tables AN4435
List of tables
Table 1. Overview of STL packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 2. Organization of the FW structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 3. Used IDEs and toolchains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Table 4. Structure of the common STL packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Table 5. Structure of the product specific STL packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 6. Integration support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 7. Compatibility between different STM32 microcontrollers . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Table 8. How to manage compatibility aspects and configure STL package . . . . . . . . . . . . . . . . . . 17
Table 9. Overview of HAL drivers used by STL stack procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 10. MCU parts that must be tested under Class B compliance . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 11. Methods used in micro specific tests of associated ST package . . . . . . . . . . . . . . . . . . . . 29
Table 12. Signals used for timing measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 13. Comparison of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 14. Possible conflicts of the STL processes with user SW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 15. Physical order of RAM addresses organized into blocks of 16 words . . . . . . . . . . . . . . . . 55
Table 16. March C phases at RAM partial test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 17. Start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Table 18. Run time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Table 19. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4/71 AN4435 Rev 9
AN4435 List of figures
List of figures
Figure 1. HSEM IDs distribution and control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2. Example of RAM configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 3. Control flow four steps check principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 4. Diagnostic LED timing signal principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 5. Typical test timing during start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 6. Typical test timing during run time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 7. Hyper terminal output window in verbose mode - Single core products. . . . . . . . . . . . . . . 47
Figure 8. Hyper terminal output window in verbose mode - Dual core products . . . . . . . . . . . . . . . . 47
Figure 9. Integration of start-up and periodic run time self tests into application . . . . . . . . . . . . . . . . 49
Figure 10. start-up self tests structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 11. CPU start-up self test structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 12. Watchdogs start-up self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 13. Flash start-up self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 14. RAM start-up self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 15. Clock start-up self test subroutine structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 16. Periodic run time self test initialization structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 17. Periodic run time self test and time base interrupt service structure . . . . . . . . . . . . . . . . . 59
Figure 18. CPU light run time self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 19. Stack overflow run time test structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 20. Clock run time self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 21. Partial Flash CRC run time self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 22. Partial RAM run time self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 23. Partial RAM run time self test - Fault coupling principle (no scrambling) . . . . . . . . . . . . . . 64
Figure 24. Partial RAM run time self tests - Fault coupling principle (with scrambling) . . . . . . . . . . . . 64
AN4435 Rev 9 5/71
5
Reference documents AN4435

1 Reference documents

Several ST documents can be used when applying or modifying the STL stack or when developing a new one, and complete testing report can be provided upon request.
Specific safety manuals for STM32 products (based on Arm preparation, where compliance aspects with other safety standards are provided.
plication notes describing specific methods to control peripherals or to ensure system
Ap electromagnetic compatibility (EMC) against noise emission and noise sensitivity are available on www.st.com.
For more information about errors handling techniques refer to Handling of soft errors in STM32 applications (AN4750).
For more information on EMC refer to the following application notes:
Softwa
EMC design guide (AN1709)
For more detailed information about cyclic redundancy check calculation (CRC) refer to
Using the
re techniques for improving microcontroller EMC performance (AN1015)
CRC peripheral in STM32 family (AN4187).
(a)
cores) are available or in
The following safety manuals are available on ww
UM17
UM1814 (for the F1 Series)
UM1845 (for the F2 Series)
UM1846 (for the F3 Series)
UM1840 (for the F4 Series)
UM2318 (for the F7 Series)
UM2455 (for the G0 Series)
UM2454 (for the G4 Series)
UM2331 (for the H7 Series)
UM2037 (for the L0 Series)
UM1813 (for the L1 Series)
UM2305 (for the L4 and L4+ Series)
UM2752 (for the L5 Series)
The development of safety manuals for other Series is an ongoing process. Contact your
al FAE or the nearest ST office to check for the availability of new documents.
loc
41 (for the F0 Series)
w.st.com:
a. Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
6/71 AN4435 Rev 9
AN4435 Package variation overview

2 Package variation overview

The STL packages and included HAL FW are summarized in Tab le 1.

Table 1. Overview of STL packages

STM32
Series
HAL driver CMSIS driver
F0 Rev. 1.5.0 Rev. 2.3.1
Common STL stack
Specific test
(1)
Included projects
SMT32052B-EVAL
F1 Rev. 1.1.1 Rev. 4.2.0 STM3210C-EVAL
F2 Rev. 1.2.1 Rev. 2.2.0 STM322xG_EVAL
F3 Rev. 1.4.0 Rev. 2.3.1 SMT32373C-EVAL
F4 Rev. 1.7.1 Rev. 2.6.1 STM324xG_EVAL
Rev. 2.2.0
F7 Rev. 1.2.2 Rev. 1.2.0 STM32756G-EVAL
L0 Rev. 1.8.1 Rev. 1.7.1 STM32L0xx_Nucleo
L1 Rev. 1.3.0 Rev. 2.2.1 STM32L152D-EVAL
L4 Rev. 1.7.1 Rev. 1.3.1 STM32L476G-EVAL
H7 Rev. 1.5.0
STM32734I-EVAL
G0 Rev. 1.2.0 STM32G081B-EVAL
Rev. 2.3.0
G4 Rev. 1.0.0 STM32G474RE_NUCLEO
WB Rev. 1.1.0 P-NUCLEO-WB55
L5 Rev 1.3.0 Rev 1.0.3 Rev 2.4.0 STM32L552ZE_Nucleo
(2)
H7
1. There are negligible differences between the STL stack versions. For more details refer to the firmware release notes. The stack modifications needed when user migrates and combines older versions of the stack with the latest HAL drivers and compilers are described in Section 3.10.
2. Support for dual core products.
Rev 1.9.0 Rev 3.0.0 STM32H747I-DISCO
The firmware uses a common structure of directories. It is based on available set of drivers either dedicated to a given product, or associated with specific HW development tools. Part of that is common with the whole STM32 family and ST debug support.
The basic structure is detailed in Table 2, where self test procedures and methods targeting the Class B requirements are collected under common STL stack and product specific STL stack directories. The remaining drivers are mostly application specific, and are subject to change or replacement in the final customer project, in accordance with user application HW.
Directory Drivers Comment
Drivers
Utilities CPU, Fonts, Log Common debug/development support

Table 2. Organization of the FW structure

BSP Evaluation board specific drivers
CMSIS Core specific drivers
HAL Product specific peripheral drivers
AN4435 Rev 9 7/71
70
Package variation overview AN4435
Table 2. Organization of the FW structure (continued)
Directory Drivers Comment
Middleware Common STL stack Common STM32 STL procedures
Product and tools dependent specific
Projects/xxxxxx_EVAL or Projects/xxxxxx_Nucleo
Integration example
Product Specific STL stack
procedures and configurations of evaluation board and integration example
Product and tools dependent STL procedures and configurations
The included projects for specific STM32 products and dedicated evaluation boards have been prepared and tested with the environments and toolchains detailed in
IDE STL Rev. 2.2.0 STL Rev. 2.3.0 STL Rev. 2.4.0 and 3.0.0
IAR™ EWARM Rev. 7.80.4 Rev. 8.32.4 Rev. 8.40.2
Keil® MDK-Arm
®
Eclipse™ Rev. 1.13.1 Rev. 1.17.0 2019-09 CDT Rev. 9.9.0

Table 3. Used IDEs and toolchains

Rev. 5.23 Rev. 5.27 Rev. 5.31
Tabl e 3.
STM32CubeIDE - Rev. 1.0.0 Rev. 1.4.2
The detailed structure of these projects and the list of files included in the common and specific parts of STL stack are summarized in
Tabl e 4 and Tab l e 5, respectively. Additional
supporting files used in the examples are listed in Tab le 6.
STL
Start-up test
Run time test

Table 4. Structure of the common STL packages

Common STL stack source files
File Description
(1)
(1)
Start-up STL flow control
Run time STL flow control
stm32xx_STLstartup.c
stm32xx_STLclockstart.c Clock system initial test
stm32xx_STLmain.c
stm32xx_STLclockrun.c Partial clock test
stm32xx_STLcrc32Run.c Partial Flash memory test
stm32xx_STLtranspRam.c Partial RAM test
8/71 AN4435 Rev 9
AN4435 Package variation overview
Table 4. Structure of the common STL packages (continued)
Common STL stack source files
STL
File Description
stm32xx_STLclassBvar.h Definition of Class B variables
stm32xx_STLlib.h Overall STL includes control
stm32xx_STLstartup.h Initial process STL header
Headers
1. As version 3.0.0 supports dual core products, files stm32xx_STLstartup.c and stm32xx_STLmain.c are replaced by, respectively, stm32_STLstartup_DualCore.c and stm32xx_STLmain_DualCore.c. Files stm32_STLcrcSW.c, stm32_STLcrcSWRun.c, and stm32_STLcrcSW.h, are included additionally into the STL common package to support software CRC calculation on the Flash memory by the secondary core.
stm32xx_STLmain.h Run time process STL header
stm32xx_STLclock.h Clock test header
stm32xx_STLcpu.h CPU test header
stm32xx_STLcrc32.h Flash memory test header
stm32xx_STLRam.h RAM test header

Table 5. Structure of the product specific STL packages

Product specific STL stack source and header files
STL
Files Description
stm32xxxx_STLcpustartIAR.s stm32xxxx_STLcpurunIAR.s stm32xxxx_STLRamMcMxIAR.s
Source
stm32xxxx_STLcpustartKEIL.s stm32xxxx_STLcpurunKEIL.s stm32xxxx_STLRamMcMxKEIL.s
Start-up and run time CPU and RAM tests written
in Assembler for IAR™, Keil® and GCC
stm32xxxx_STLcpustartGCC.s stm32xxxx_STLcpurunGCC.s stm32xxxx_STLRamMcMxGCC.s
Header stm32xxx_STLparam.h STL product specific configuration file

Table 6. Integration support files

Files supporting implementation of STL in the integration example
startup_stm32xxxxxIAR.s C start-up for IAR™ compiler
startup_stm32xxxxxKEIL.s C start-up for Arm® compiler
startup_stm32xxxxxGCC.s C start-up for GCC compiler
main.c Main flow of the example source
stm32xxxx_hal_msp.c Application specific HAL drivers initialization
stm32xxxx_it.c
STL Interrupts, clock measurement processing and configuration procedures
main.h Main flow header
stm32xxxx_hal_conf.h HAL drivers configuration file
stm32xxxx_it.h ISR header
AN4435 Rev 9 9/71
70

Main differences between STL packages from product point of view AN4435

3 Main differences between STL packages from
product point of view
Users can find some small differences, mainly due to hardware differences between the products and to incompatibilities of compilers and debugging tools.
The main differences are due mainly to compatibility aspec products, all based on Arm
These differences, summarized in Tab le 7, are described in this section.
®
cores.
ts between different STM32
10/71 AN4435 Rev 9

Table 7. Compatibility between different STM32 microcontrollers

STM32
Series
Arm® Cortex
core(s)
Technology 180 nm 180 nm 90 nm 90 nm 90 nm 180 nm 90 nm 90 nm 40 nm 110 nm 130 / 110 nm 90 nm 90 nm 90 nm
Frequency 48 MHz 24-72 MHz 120 MH z 64 MHz 150 MHz 72 MHz 168 MHz 216
Performance 38 DMIPS 61 DMIPS 150 DMIPS 59 DMIPS 190 DMIPS 61 DMIPS 210 DMIPS 462 DMIPS 856 DMIPS 1327 DMIPS 26 DMIPS 33 DMIPS 100 DMIPS 165 DMIPS DMIPS
Flash memory 16-128 KB 16-1024 KB 128-1024 KB 16-512 KB 128-1024 KB 32-256 KB 128-2048 KB 512-2048 KB 128-2048 KB 2048 KB 32-192 KB 32-512 KB 128-1024 KB 256-512 KB 256-1024 KB
ECC on
Flash memory
CRC
configurable
RAM 4-16 KB 4-96 KB 64-128 KB 8-128 KB 32-128 KB 16-48 KB 64-256 KB 256-512 KB 1024 KB 8-20 KB 4-80 KB 4-320 KB 256 KB 256 KB
AN4435 Rev 9 11/71
RAM parity
/scrambling
Auxiliary RAM No No Yes No CCM RAM
Data EEPROM - - - - - - - - - 2 KB 2-16 KB - - -
EEPROM ECC - - - - - - - - - Yes Yes - - -
IWDG
window option
Clock system
Clock cross
reference
measurement
Clock reference
next options
Voltage scaling
management
1. Available on some products only.
2. When product features SRAM parity bit, address is included, except the STM32F0 Series where parity is computed only over data.
3. Parity bit does not cover the whole RAM, but only a portion of it. Check the product datasheet for detailed info.
4. Embedded RAM features ECC.
5. All the family members feature HSI16, HSE, PLL, LSI and LSE clock sources. Additional sources are listed in the table.
6. Timers dedicated to clock cross reference measurements are 16-bit wide, except STM32F2, STM32F4, STM32F7 and TIM5 of STM32G4, where 32-bit ones are used.
7. TIM16/Ch1 is used for STM32F30xx.
F0 F1 F3 G0 G4 F2 F4 F7 H7
®
M0 M3 M4 M0+ M4 M3 M4 M7 M7 M7 and M4 M0+ M3 M4 M33 M4
No No Yes
Yes No No Yes Yes Yes No Yes Yes Yes No Yes Yes Yes
(2)
Yes /Ye s N o/ Ye s N o/ No Yes /N o Yes
Yes No No Yes Yes Yes No Yes Yes Yes No Yes Yes Yes
HSI14, HSI48
(5)
(LSI~40 kHz)
TIM14/Ch1 TIM5/Ch4
(6)
GPIO, RTC,
HSE/32,
Yes
(LSI~40 kHz) (LSI~32 kHz) (LSI~32 kHz)
MCO
(1)
Mainstream Performance Low-power Wireless
(1)
MHz 400 MHz 480/240 MHz 32 MHz 32 MHz 80 MHz 110 Mhz 64 MHz
(1)
TIM5/Ch4
GPIO, RTC,
­LSI, LSE
No Yes
(1)
(1)
Yes Yes Yes
(3)
/No No/No No/No No/No No
(1)
HSI48
(LSI~32 kHz)
(7)
TIM16/Ch1 TIM16/Ch1 TIM14/Ch1 TIM5/Ch4 TIM5/Ch4 TIM16/Ch1 TIM16/Ch1 TIM21/Ch1 TIM10/Ch1 TIM16/Ch1 TIM16/Ch1 TIM16/Ch1
LSE,
MCO
MCO HSE/32
RTC LSE
HSE/32,
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
(1)
CCM RAM
No External only Yes, embedded CRC unit Yes No Yes Yes Yes
(1)
Yes Yes TCM, backup No No Yes Backup Backup
(LSI~40 kHz) (LSI~32 kHz) (LSI~32 kHz) CSI, HSI48, (LSI~32 kHz)
GPIO, RTC,
HSE/32,
MCO
GPIO, RTC,
LSI, LSE
GPIO, RTC,
LSI, LSE
LSE CSI
HSE_1MHz
MCO1, MCO2
H7 dual
core
(4)
/No No/No No/No Yes
LSE CSI
HSE_1MHz
MCO1, MCO2
L0 L1 L4 L5 WB
MSI, HSI48
(LSI~38 kHz)
GPIO, MSI,
LSI, LSE
HSE_RTC
MSI
(LSI~38 kHz)
GPIO, RTC,
LSI, LSE
(3)
/No Yes
MSI, HSI48 (LSI~32 kHz)
GPIO, RTC, LSI, LSE, MSI, HSE/32, MCO
(1)
(3)
/No Yes
MSI, HSI48
(LSI~32 kHz)
LSE, RTC
(3)
/No
MSI, HSI48
(LS1/2I~32
kHz)
LSE RTC
MSI HSE/32
MCO
AN4435 Main differences between STL packages from product point of view
(1)
Main differences between STL packages from product point of view AN4435

3.1 CPU tests

Some specific operations are inaccessible by high level compilers. That is why code for both start-up and run time tests are written in assembly, and differs slightly in mnemonics among used compilers.
These tests are product dependent, as sets of available instructions differ between Cortex® cores used by STM32 microcontrollers. As an example, due to restricted instruction set of
®
Arm
Cortex®-M0+ core, instructions loading immediate 32-bit constant operands are
replaced by instructions loading those constants placed at code memory.
When user applies a contemporary version of compiler to an older version of the STL, the assembly testing routine applied at startup can become incompatible and require adaptations. For more information refer to
versions of the STL.
Section 3.10: Incompatibility with previous

3.2 Clock tests and time base interval measurement

Internal timers are used to cross-check frequency measurements. This method is required to determine harmonic or sub-harmonic frequencies when the system clock is provided by an external crystal or ceramic resonator, or to detect any significant discrepancy in the application timing. Different product dependent timers are dedicated to perform such cross check measurement.
Initial configuration of the specific timers is slightly different while dedicated interrupt vectors are used for the measurement in dependency on concrete timer at given device.
Some older products do not support cross-reference measurement feature.
If the system clock doesn't use the HSE quartz clock, user can set up the clock measurement HSI vs. LSI commenting out the parameter HSE_CLOCK_APPLIED in the stm32xx_STLparam.h file or adapting the clock measurement to be based on another reliable clock source (e.g. line power frequency) to satisfy the standard requirements for the clock monitoring.
In any case, if the cross check measurement depends upon the RC clock (HSI or LSI), user has to consider the accuracy of such a clock source over the whole temperature range. This is necessary to prevent any false clock failure detection, especially when the unit under self test has to operate over a wider temperature range. User can apply an adaptable clock test algorithm while monitoring the trend of the ambient temperature, or consider a more accurate source to be taken as a clock reference.
Clock security system hardware feature (CSS) is activated by default by the library during startup test as a supplementary testing method if HSE is used as system clock (see stm32xx_STLclockstart.c file).

3.3 SRAM tests

Hardware techniques that ensure single bit redundancy protection of both data words and their addresses are the minimum requirement to fulfill the associated standards on volatile memories (to detect errors not only in areas dedicated to data, but also on their internal address and data path). Some of the older ST products do not feature this (partial or full) hardware redundancy, and then these requirements shall to be met indirectly by applying proper software methods, better if in combination with hardware.
12/71 AN4435 Rev 9
AN4435 Main differences between STL packages from product point of view
Unfortunately, execution of these tests uses a portion of microcontroller computing power, and makes overall diagnostic tests longer. As a consequence, software methods are applicable on static errors only. Even very sophisticated tests are not able to cover transient errors efficiently, so their diagnostic coverage is limited.
The SRAM test must follow a topological pattern. Testing by word can be used as logically adjacent bits (belonging to a single word) are physically far away from each other split in the array, while pairs of words with subsequent logical addresses share physically adjacent neighbor cells (bits). In addition, when the sequence of addresses is not regular (as in some older STM32 products), the physical order of words addresses (so called scrambling) has to be respected during this test.
User has to ensure that a proper test corresponding to the RAM design is implemented for the product used in the application. This is done by definition of ARTISAN symbol for the assembly compiler. This symbol has to be defined for STM32F0xx, STM32F1xx and STM32F3xx products exclusively.
Optionally, user can simplify and speed-up the Marching C- algorithm used during run time testing when USE_MARCHX_TEST symbol is applied. If this symbol is defined, two middle marching steps are skipped and not implemented during the transparent test (see
Section 6.4.7: Partial RAM run time self test). It is suggested to keep full March C- algorithm
at least during the initial test.
Some ST microcontrollers feature a built-in word protection with single bit redundancy (hardware parity check) applied on CCM RAM or at least on a part of the SRAM. This hardware protection is one of the acceptable methods required by the IEC IEC
60730. The built-in parity feature includes address and data with the exception of the
60335 and
STM32F0 Series, where the parity is only computed with the data.
Despite the hardware method is recognized by the standard, it is advised to keep the execution of software March test and the data redundancy as supplementary safety methods for the volatile memory testing, and not to rely exclusively on the hardware (the main reason is that there is no way how to test functionality of the parity feature during run time).
Reliability of the information stored in the SRAM can be increased by applying additional indirect testing techniques, such as double storage of safety critical information in physically separated areas in the form of two inverted patterns (this is based on the fact that corruption caused by radiation or EMI usually attacks a limited physical memory section), or by applying dedicated check sum signature to each part of these data.
The hardware RAM parity check is an optional feature. When enabled, it is advised to perform a SW initialization of the whole RAM at the beginning of the code execution, to avoid getting parity errors when reading non-initialized locations (this is the case of local variables when they are allocated and read out while using different data access to memory). The best way to do this is during start-up procedure. A simple loop inserted into start-up assembly code can solve the problem and initialize parity system in the dedicated RAM area:
; Program starts here after reset
;------------------------------------------------------------------------
Reset_Handler
; Parity system initialization has to be performed here prior to the
; startup self-test procedure
AN4435 Rev 9 13/71
70
Main differences between STL packages from product point of view AN4435
;------------------------------------------------------------------------
; r0 is used as a pointer to RAM,
; r1 keeps end address of the area
;------------------------------------------------------------------------
;At every step of the loop, the 32-byte block (r2-r9) is copied to RAM
; starting from address kept at r0, r0 is then increased by 32
; the loop body is performed while r0<r1
LDR R0, =RAM_block_begin
ADD R1, R0, #RAM_block_size
RAM_init_loop
STMIA R0!, {R2-R9}
CMP R0, R1
BLT RAM_init_loop
; RAM is initialized now, program can continue by startup self-test
LDR R0, =STL_StartUp
BLX R0
Note: The real content of the registers copied by STMIA instruction is not relevant because the
purpose of this loop is to initialize the parity system. The RAM content is initialized at a later stage by the compiler standard start-up procedure. RAM_block_begin, RAM_block_size and end memory address setting must be aligned with the number of data copied by STMIA instruction to prevent any undefined memory access, especially at the end of the loop.
Note: For new products featuring optional HW initialization of the SRAM, there is no need to
perform initialization of the memory by the upper SW loop if the user activates this option.
When the initial software March test is performed over a RAM area dedicated to stack, it destroys all the stack content including the return address of the test routine itself stored there when high level compiler is used. The store and restore procedure of the return address depends on the compiler implementation and can differ for different optimization levels. Besides an optimization effort, this is main reason why the routines supporting SRAM testing are written in assembly, to be independent from the higher compiler implementation. On the other side this solution brings a light tool dependency, and different assembly source files have to be kept to pass their compilation correctly.
When user applies a contemporary version of compiler to older version of the STL the assembly testing routine applied at startup can become incompatible and require small adaptations. For more information see
Section 3.10: Incompatibility with previous versions
of the STL.

3.4 Flash memory integrity tests

Flash memory test is based on built-in HW CRC unit. Some of the STM32 microcontrollers feature configurable units so that the initial configuration can differ slightly, however the polynomial calculation used is the same for all the products.
User must comment definition of parameter CRC_UNIT_CONFIGURABLE in the stm32xx_STLparam.h configuration header file for all products where CRC is not configurable.
The area where the pattern of CRC calculation is stored has to be excluded from the range of the calculation. The boundaries of the checked area must be aligned with multiples of
14/71 AN4435 Rev 9
AN4435 Main differences between STL packages from product point of view
tested block size used during the test. By default, the block size is set to 16 words (64 bytes) by parameter FLASH_BLOCK_WORDS defined in the stm32xx_STLparam.h file. Unused memory areas included in the check have to be identified with predefined values. An all-1 pattern is used by default.
The range under the nonvolatile memory test is defined by the user. During run time, if the test of the overall memory range is not acceptable because too long, the user can split it into segments that correspond to local areas where the program is being executed. This requires to dynamically modify the area under test, so that the testing is performed exclusively over those areas.
The STL integration examples perform tests of single contiguous areas described by single check sum descriptor. When user considers additional separated segments, the test procedure has to be adapted, as done in the X-CUBE-STL library targeting SIL.
The result of the CRC calculation has to be compared with the corresponding reference pattern provided either automatically by compiler (IAR™ case) or added by the end user from a computation handled externally (MDK-Arm
®
and GCC cases).
When the tool does not support CRC pattern placement, specific script files (crc_gen_keil.bat or crc_gen_gcc.bat) are provided in the implementation example projects to run post-built procedures calculating the check sum automatically. They are based on installation of Srecord GNU tool, freely available from http://srecord.sourceforge.net. Default HEX file provided by the linker output is modified and the CRC reference pattern is inserted in a new HEX file. User has to ensure that the modified HEX file (output_name_CRC.hex) is used for the application download (e.g. by implementation of crc_load.ini file or by proper modification of launch configuration properties when debug or download session starts).
When testing the Flash memory integrity, CRC computation done via hardware CRC generator decreases significantly the CPU load. The Flash memory can be tested while DMA is used for feeding CRC block, too. In comparison with software test, the CPU load decreases significantly when DMA is applied but the speed of the test itself doesn't change so much, because DMA needs at least a few cycles to read and transfer data. The test can even slow down when DMA services some other transfers or interrupts in parallel. Moreover some additional DMA configuration is required at initialization of the test. User can find detailed information about use of DMA for CRC calculation in AN4187.
Some of the oldest STM32 devices do not feature the CRC hardware block and use software routines for CRC computation. Former versions of the STL based on obsolete SPL libraries provide 16-bit wide calculation method based on predefined look-up table constants to speed up the calculation.

3.5 Specific aspects concerning TrustZone controller

When dealing with TrustZone security controller (used by STM32L5 Series, based on the security-oriented Arm areas is to be handled with care.
No issues are expected for CPU registers used for the test, common for both the secure and non-secure execution state, except for register R13, which is kept separately (the one related to the ongoing state is for test only). This is also the case for memory regions when the associated tests are applied at the non-secure state while any TrustZone security is disabled.
®
Cortex® M33 core) the accessibility of the tested parts and memory
AN4435 Rev 9 15/71
70
Main differences between STL packages from product point of view AN4435
Once this security is enabled, all the memory areas can be accessed and tested only under the secure state, or user has to separate and split their testing strictly into two parts related to the secure and non-secure state execution (e.g. a case when the non-secure code size and its CRC check sum is not known in advance).
In such case, user has to consider and prevent possible cross collisions between the secure and non-secure state execution (e.g. when the secure or non-secure state interrupt accesses data from RAM area under modification or test of the complementary state at the same time, or if hardware CRC unit calculation is shared contemporary between the states for different purposes).
The non-secure state can still use and call APIs related to the secure state, provided these APIs to be shared are properly published and mapped via secure gateway.

3.6 Start-up and system initialization

There are differences between initial system configuration and setup of debug and diagnostic utilities (e.g. recognizing reset cause) because of hardware deviations, dedicated debugging tools and used compilers. Standard product start-up file (tool-dependent) is modified to include a set of start-up tests at the very beginning.

3.7 Firmware configuration parameters

All the STL configuration parameters and constants used in the STL code written at C-level are collected into one file, stm32xx_STLparam.h. Configuration differences respect mainly different sizes of tested areas, different compilers and slight deviations of control flow.
User must be careful, when modifying the initial or run time test flow, of possible corruption of the implemented control flow. In this case, values summarized at complementary control flow counters can differ from the constants defined for comparison at flow check points (see
Section 5.1.3: Flow control procedure). To prevent any control flow error, user must change
definition of these constants in an adequate way.
There are a few parameters to be defined for dedicated assembly compiler, for more details see
Tool specific integration of the library.
Configuration options are summarized in Table 8.
16/71 AN4435 Rev 9
AN4435 Rev 9 17/71

Table 8. How to manage compatibility aspects and configure STL package

Feature IAR™-EWARM MDK-Arm
®
Arm
Cortex® core Include proper CPU testing start-up and runtime procedures, proper handling of core hard faults and exceptions
Frequency (MHz)
Handling SYSTCLK_AT_RUN_HSE / SYSTCLK_AT_RUN_HSI / HSE_VALUE / HSE_CLOCK_APPLIED / LSI_Freq parameters in
stm32xx_STLparam.h
Handling ROM_START / ROM_END in
stm32xx_STLparam.h
Setup LR_IROM1 load region in
Flash memory
density (KB)
Handling Checksum option in Project linker option menu ROM_region in project icf. file
project sct file.
Define Check_Sum pattern placement either in startup_stm32yyyyxxKEIL.s or in project.sct file. Implement proper post-built script files for the automatic CRC check sum calculation.
ECC on Flash Implement handling ECC event by interrupt or by pulling
CRC configurable Handling CRC_UNIT_CONFIGURABLE parameter in stm32xx_STLparam.h
®
Handling ROM_START / ROM_END in
stm32xx_STLparam.h
Define Flash memory region in project ld file. Implement proper post-built script files for the automatic CRC check sum calculation
AN4435 Main differences between STL packages from product point of view
GCC
Setup RAM_BUF, RAM_PNT, CLASSB, CLASB_INV RW_IRAM1 in project sct file
Handling RAM_START, RAM_END, CLASS_B_START, CLASS_B_END parameters in stm32xx_STLparam.h
RAM density (KB)
Setup RUN_TIME_RAM_BUF_region, RUN_TIME_RAM_PNT_region, CLASS_B_RAM_region, CLASS_B_RAM_REV_region, RAM_region in project icf. file
RAM parity Handling RAM parity event by interrupt or by pulling
RAM scrambling
(1)
March-X flow during
transparent
RAM test
Define ARTISAN=1 in Project Assembler / Preprocessor option menu when scrambling is applied
Define USE_MARCHX_TEST=1 in Project Assembler / Preprocessor option menu when the flow is applied
Define ARTISAN=1 in Option for Target / Asm / Conditional assembly control symbols menu when scrambling is applied
Define USE_MARCHX_TEST=1 in Option for Target / Asm / Conditional assembly control symbols menu when the flow is applied
ECC on E2PROM Implement handling ECC event by interrupt or by pulling
IWDG option Handling IWDG_FEATURES_BY_WINDOW_OPTION parameter in stm32xx_STLparam.h
Define CLASSBRAM and RAM regions in project ld file.
Handling RAM_START, RAM_END, CLASS_B_START, CLASS_B_END parameters in stm32xx_STLparam.h.
Define ARTISAN=1 in Properties for Assembly / Tool Settings / MCU GCC Assembler / General / Assembler Flags when scrambling is applied.
Define USE_MARCHX_TEST=1 in Properties for Assembly / Tool Settings / MCU GCC Assembler / General / Assembler Flags when the flow is applied.
18/71 AN4435 Rev 9
Feature IAR™-EWARM MDK-Arm
Table 8. How to manage compatibility aspects and configure STL package (continued)
®
GCC
Clock cross
reference
Setup proper timer system for cross reference measurement and handling its events
measurement
Define SUPERSET_DUAL_CORE, DUAL_CORE_MASTER, DUAL_CORE_SLAVE to include associated control of dual core
Dual core specific
setting
synchronization. Define SW_CRC_32 flag to select 32-bit software CRC calculation. Adapt optionally MAX_NUMBER_OF_MISSED_SLAVE_CORE_CYCLES and HSEM IDs HSEM_ID_CLASSB_SLAVE_SELFTEST,
HSEM_ID_CLASSB_SLAVE_CYCLE and HSEM_ID_CLASSB_MASTER_SELFTEST.
Handling STL_VERBOSE_POR, STL_VERBOSE, STL_EVAL_MODE, STL_EVAL_MODE_SLAVE, STL_EVAL_LCD, NO_RESET_AT_FAIL_MODE, DEBUG_CRC_CALCULATION, STL_USER_AUX_MODE, USE_WINDOW_WDOG,
Debugging option
(2)
USE_INDEPENDENT_WDOG, HSE_CLOCK_APPLIED, IGNORE_COMPLEMENTARY_CORE_STATUS parameters in
stm32xx_STLparam.h
1. Tool specific procedures (source code written in assembler).
2. Evaluation board specific and STL optional handling when debugging the FW (not part of the safety code, but used as an application integrating example). For additional
details follow associated comments in the stm32xx_STLparam.h file and in Section 5.4.3.
Main differences between STL packages from product point of view AN4435
AN4435 Main differences between STL packages from product point of view

3.8 Firmware integration

Self test procedures and methods targeting Class B requirements are provided in the project examples showing how to integrate correctly the firmware into a real application. Every integration example uses dedicated products and evaluation HW boards. Apart from common drivers and procedures, it also includes product, evaluation board or compiler specific drivers not directly related to the safety task but rather included for demonstration or debugging purposes (details are given in
Section 2: Package variation overview).
User has to take care of dedicated linker file content and project specific settings to integrate the STL stack and all the methods used properly into the target application.
Pay attention to the definition of memory areas under test (RAM and Flash), to the allocation of memory space for Class B variables and stack, and to the definition of the control flow.
Additional details are provided in the following sections of this document.

3.9 HAL driver interface

When all the debug and verbose support (UART channel, LCD display, LEDs or auxiliary GPIO signals) is removed from the packages, the interface between HAL layer and STL procedures is reduced to drivers needed to control specific peripherals used during start-up and run time self tests. An overview is given in

Table 9. Overview of HAL drivers used by STL stack procedures

Tabl e 9.
HW component HAL drivers used STL files
Core SysTick timer HAL_SYSTICK_Config stm32xx_STLmain.c
NVIC
Clock system
Timers
CRC unit
HAL_NVIC_SetPriority HAL_NVIC_EnableIRQ HAL_NVIC_SystemReset
HAL_RCC_OscConfig HAL_RCC_ClockConfig HAL_RCC_EnableCSS
HAL_TIM_IC_Init HAL_TIMEx_RemapConfig HAL_TIM_IC_ConfigChannel HAL_TIM_IC_Start_IT __TIMx_CLK_ENABLE
HAL_CRC_Init HAL_CRC_DeInit HAL_CRC_Accumulate HAL_CRC_Calculate __HAL_CRC_DR_RESET __CRC_CLK_ENABLE()
stm32xx_STLstartup.c
stm32xx_it.c
stm32xx_STLstartup.c
stm32xx_STLclockstart.c
stm32xx_STLclockrun.c
stm32xx_it.c
stm32xx_STLstartup.c
stm32xx_STLcrc32Run.c
AN4435 Rev 9 19/71
70
Main differences between STL packages from product point of view AN4435
Table 9. Overview of HAL drivers used by STL stack procedures (continued)
HW component HAL drivers used STL files
HAL_IWDG_Init HAL_WWDG_Init HAL_IWDG_Start
IWDG and WWDG
HAL layer
HAL_WWDG_Start HAL_IWDG_Refresh HAL_WWDG_Refresh __HAL_RCC_CLEAR_FLAG __HAL_RCC_GET_FLAG __WWDG_CLK_ENABLE()
HAL_Init HAL_IncTick HAL_GetTick
stm32xx_STLstartup.c
stm32xx_STLmain.c
stm32xx_STLstartup.c
stm32xx_STLmain.c
stm32xx_it.c
Note: Be careful when using a HAL version newer than that used for the STL certification, check
changes summarized in release notes. For more information refer to
Section 3.10.

3.10 Incompatibility with previous versions of the STL

User has to be careful when a different version of compiler or HAL is applied to implement the STL testing procedures (see
Tabl e 1).
The push towards optimization of code size and speed makes the providers of compilers to apply specific and more sophisticated methods of making code structure, even if users do not need these optimizations, which make the code too compressed and difficult to be analyzed or debugged.
One of the requirements is that each subroutine keeps the content of core registers R4 to R11 (this was not required with lower levels of optimization, and so not kept in Revision
2.2.0, corrected for more recent versions, for product specific startup tests written in assembly). In case of CPU test the modification is easy (it is only needed to push these registers into stack at the beginning of the procedure and restore them back before return, either by push and pop or stmdb and ldmia instructions:
STL_StartUpCPUTest:
; Save preserved registers values into stack
STMDB SP!, {R4, R5, R6, R7, R8, R9, R10, R11}
...
; Restore preserved registers values from stack
LDMIA SP!, {R4, R5, R6, R7, R8, R9, R10, R11}
BX LR ; return to the caller
Another issue related to the compiler optimization can be an unexpected replacement of the control flow (based on step by step filling of the specific dedicated flow control registers between the test caller and caller procedures) by a single last time setup of these registers by final expected values (precomputed by the compiler during compilation) just prior the program starts to check their content. This is why it is strongly suggested to set the lowest possible optimization for the stm32xx_STLstartup.c file compilation configuration.
20/71 AN4435 Rev 9
AN4435 Main differences between STL packages from product point of view
One of the crucial definition of commonly used error status enumerator is changed in HAL library so that the assembler-written STL code, which relies on the original definition, has to be either adapted or declared independently from the common operator recognized at
C-level. To make the FW independent on HAL definition of this enumerator user can define specific enumerator dedicated to the test and modify the declaration of the related test function accordingly. For example, to correctly evaluate result of RAM startup test, the stm32xx_STLRam.h file has to be modified in following way:
typedef enum
{
SRAMTEST_SUCCESS = 1,
SRAMTEST_ERROR = !SRAMTEST_SUCCESS
} SRAMErrorStatus;
and
SRAMErrorStatus STL_FullRamMarchC(uint32_t *beg, uint32_t *end, uint32_t pat, uint32_t *bckup);
while comparison of result when startup test is called in the stm32xx_STLstartup.c file has to be modified in following way:
...
if (STL_FullRamMarchC(RAM_START, RAM_END, BCKGRND, RAM_BCKUP) != SRAMTEST_SUCCESS)
{
...
The upper workaround is applied only for RAM startup test since revision 2.3.0 of the STL, while a unique STL specific enumerator STLErrorStatus is defined for all the associated testing APIs from revision 2.4.0.
There is an additional back-up pointer added as a next input parameter since revision 2.3.0 when calling the startup SRAM test procedure, not used in previous versions of the library. This is an optional solution to solve the problem seen during the CPU startup test, and to save preserved registers. The RAM_BCKUP pointer held at R3 during the call has to point at the beginning of some volatile memory area with 16 bytes capacity to save registers R4­R7 used and modified by the self test. The situation here is a bit more complicated as the test can destroy the stack content if the stack area is under test. User then has to save the preserved registers to another SRAM or into a part of memory excluded from the test. The test has to start and finish by storing and restoring the registers from the address provided by R3:
STL_FullRamMarchC:
STMIA R3!,{R4-R7} ; Save content of preserved registers R4-R7
...
LDMDB R3!,{R4-R7} ; Restore R4-R7 content
BX LR ; return to the caller
The R3 content cannot be modified by the procedure. Its original implementation has to be replaced using R7. If there is no area available for such a backup, user can adopt another optional solution and save the R4-R7 registers one by one in some RW peripheral registers not used at startup.
There can be problems with modified HEX file load at debugger entry with latest versions of the MDK-Arm
®
because it no longer performs load of the user defined initialization file as
the last action of the debugger entry, hence the Flash memory remains programmed by its
AN4435 Rev 9 21/71
70
Main differences between STL packages from product point of view AN4435
default content at the end. Only the modified HEX file keeps a valid CRC image of the code, hence the execution of the default memory integrity check fails. As a workaround, copy correct CRC pattern from the HEX file to the CHEKSUM segment definition defined at the end of the startup_stm32xxxx.s modified assembly file (KEIL compiler case), or directly at segment placing the check sum result at linker script file (GCC compiler), and recompile the project with the correct CRC pattern copy after modifications of the source files. Another debugging option is to define DEBUG_CRC_CALCULATION conditional flag during compilation, when the CRC result calculated during the start up test is applied for the run time test, whatever the CHECKSUM segment content.
With the latest versions of the IAR compiler user can face problem with segment placement in the RAM. This is due to overlay of the common read/write section and class B related sections in the region defined by the provided icf linker file. User has to separate the content of these sections by changing the definition of the common section start to put it out of the class B sections range:
...
define symbol __ICFEDIT_region_CLASSB_end__ = 0x2000007F;
define symbol __ICFEDIT_region_user_RAM_start__ = 0x20000080;
define region RAM_region = mem:[from __ICFEDIT_region_user_RAM_start__ to __ICFEDIT_region_RAM_end__];
place in RAM_region { readwrite, rw section .noinit };

3.11 Dual core support

The main difference between STL library versions 2.x.x and 3.0.0 is the added support of communication and synchronization between testing processes running in parallel on two embedded cores, to provide the firmware solution for dual core products. Both cores perform standard standalone single core testing procedures adopted by versions 2.x.x in parallel, with exceptions described in this section.
The core that plays the role of master overtakes the configuration control and testing of the common clock system during startup and run time. The slave core does not perform any clock control.
Each core uses and tests its own watchdog system independently. No common reset is adopted. User can enable it by hardware configuration, or enable specific interrupts for reciprocal monitoring of the window watchdog activity.
To prevent any competition of the embedded hardware CRC unit occupancy, the slave core does not use this unit for its non-volatile memory verification but applies software calculation.
Two newly added files stm32xx_STLcrcSW.c and stm32xx_STLcrcSWRun.c collect the dedicated lookup tables loop cycles with all the associated data sets and step by step handling of the memory test at run time per blocks. The files include conditionally compiled parts handled by definition of SW_CRC_32 flag (defined at common parametrization stm32xx_STLparam.h header file) selecting either 16-bit or 32-bit CRC calculations upon 0x11021 and 0x104C11DB7 polynomials recognized by IEEE standard. This is a flexible tool for the end user to select procedures sufficient to ensure the required reliability with respect to performance and mainly memory capacity available in the application (to accommodate look up table data).
22/71 AN4435 Rev 9
Loading...
+ 49 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use