ST STM32F2 Series User Manual
  1. Manuals
  2. Brands
  3. ST Manuals
  4. Microcontrollers
  5. STM32F2 Series
  6. User manual

ST STM32F2 Series User Manual

Hide thumbs Also See for STM32F2 Series:
Table of Contents

Advertisement

Quick Links

Download this manual See also: User Manual
UM1845
User manual
STM32F2 Series safety manual
Introduction
This document describes how to use the microcontrollers of the STM32F2 Series in the context of a safety-related system,
specifying the user's responsibilities for installation and operation in order to reach the targeted safety integrity level.
This manual applies to the microcontrollers of the STM32F2 Series and to X-CUBE-STL part number.
System designers can avoid going into the details of the functional safety standards application of the STM32F2 Series by
following the indications reported in this manual.
This manual is written in compliance with IEC 61508. It indicates how to use the STM32F2 Series microcontrollers in the context
of other functional safety standards such as safety machine directives ISO 13849.
The safety analysis summarized in this manual takes into account the variation in terms of memory size, internal peripheral
®
®
number and package among the different part numbers of the Arm
Cortex
-M3 based STM32F2 Series microcontrollers.
This manual has to be read along with the technical documentation for the related part numbers (such as reference manuals
and datasheets) available on www.st.com.
UM1845 - Rev 4 - August 2018
www.st.com
For further information contact your local STMicroelectronics sales office.

Advertisement

Table of Contents
loading
Need help?

Need help?

Do you have a question about the STM32F2 Series and is the answer not in the manual?

Questions and answers

Subscribe to Our Youtube Channel

Related Manuals for ST STM32F2 Series

Summary of Contents for ST STM32F2 Series

  • Page 1 This manual is written in compliance with IEC 61508. It indicates how to use the STM32F2 Series microcontrollers in the context of other functional safety standards such as safety machine directives ISO 13849.

  • Page 2: About This Document

    Terms and abbreviations Abbreviations related to STM32F2 Series hardware modules (like DMA, GPIO etc.) are the same than the ones used in STM32F2 Series technical documentation. See the following table for a list of acronyms used in this document. Table 1.

  • Page 3: Reference Normative

    Software Read also the following definitions used within this manual: • End user: the STM32F2 Series final user of that is in charge of integrating the MCU in a real application (for example an electronic control board). • Application software: the actual software running on the STM32F2 Series MCUs and implementing the safety function.
  • Page 4 UM1845 Reference normative IEC 61508 requirement (part 2 annex D) Reference D2.2 a) the failure modes of the compliant item due to random hardware failures, that result in a failure of the function and that are not detected by diagnostics internal to the compliant item; D2.2 b) for every failure mode in a), an estimated failure rate;...

  • Page 5: Stm32F2 Series Microcontroller Development Process

    • Automotive safety: a subset of the automotive domain. ST uses as a reference the ISO 26262 Road vehicles Functional safety standard. ST supports customer inquiries regarding product failure rates and FMEDA to support hardware system compliance to established safety goals.
  • Page 6 UM1845 STMicroelectronics standard development process Figure 1. STMicroelectronics product development process 2 Design & 3 Qualification 1 Conception validation · Semiconductor design · Key characteristics and · Successful completion of development requirements related to future the product qualification · Hardware and application uses of the device plan ·...

  • Page 7: Reference Safety Architecture

    Other components might be related to the compliant item, like the external HW components needed to guarantee either the functionality of the STM32F2 Series (external memory, clock quartz etc) or its safety (for example the external watchdog, voltage supervisors).

  • Page 8: Reference Safety Architectures - 1Oo1

    According to above reported definition for implemented safety functions, the compliant item i.e. the element can be regarded as type B (as per IEC61508-2, 7.4.4.1.2 definition). Despite accurate, exhaustive and detailed failure analysis has been done for STM32F2 Series, this device has to be considered intrinsically complex and therefore type B classification is appropriate.
  • Page 9 1oo1 reference architecture. Safety integrity of each channel is guaranteed by the combination of STM32F2 Series internal processes (implemented safety mechanisms) and external processes WDTe and VMONe. Safety integrity of overall compliant item is guaranteed by the external voter PEv allowing to claim HFT=1.

  • Page 10: Assumed Requirements

    STM32 MCU to detect and react to a failure. That time corresponds to the portion of the Process Safety Time allocated to STM32F2 Series MCUs (“STM32xx Series duty” in the figure below) in error reaction chain at system level.

  • Page 11: Electrical Specifications And Environment Limits

    • Operating conditions. Due to the large number of STM32F2 Series part numbers, the related user manuals and datasheets are not listed in this document; users are responsible to carefully check the above reported limits in the technical documentation on the related part number available on .

  • Page 12: Table 4. Safety Mechanism Field Explanation

    Description of hardware and software diagnostics Note that each part number of the STM32F2 Series owns different combinations of peripherals (for instance, some of them are not equipped with USB peripheral). To reduce the number of documents and avoid information- less repetitions, the current Safety Manual (and therefore this section) addresses the overall possible peripherals available in the targeted part numbers.

  • Page 13: Arm Cortex -M3 Cpu

    Multiple faults protection CPU_SM_5 : external watchdog Recommendations and known This method is the main asset in STM32F2 Series safety concept. CPU integrity is a key factor, given limitations that the major part of defined diagnostics for MCU peripherals are software-based Table 6.

  • Page 14: Table 7. Cpu_Sm_2

    UM1845 Description of hardware and software diagnostics SM CODE CPU_SM_1 Fault detection time Depends on implementation. Higher value is fixed by watchdog timeout interval. Addressed fault model Permanent and Transient Dependency on MCU None configuration Initialization Depends on implementation Periodicity Continuous Test for the diagnostic Multiple faults protection...

  • Page 15: Table 9. Cpu_Sm_4

    UM1845 Description of hardware and software diagnostics SM CODE CPU_SM_3 Error reporting High-priority interrupt event Fault detection time Depending on implementation, refer to functional documentation Addressed fault model Permanent and Transient Dependency on MCU configuration None Initialization None Periodicity Continuous It is possible to write a test procedure to verify the generation of the HardFault exception;...

  • Page 16: Table 11. Cpu_Sm_6

    It is recommended to carefully check the assumed requirements about system safe state reported in Section 3.3.1 It also contributes to reduce potential common cause failures, because the external watchdog is clocked and supplied independently from the STM32F2 Series Error reporting Depends on implementation Fault detection time...

  • Page 17: Table 13. Mpu_Sm_0

    Hardware random-failure detection capability for MPU is restricted to well-selected failure modes, mainly affecting program counter and memory access CPU functions. The associated diagnostic coverage is therefore expected to be not relevant in the framework of STM32F2 Series safety concept Table 13.

  • Page 18: Embedded Flash Memory

    Periodical software test for Flash memory Ownership End user or ST Permanent faults affecting the system Flash memory, memory cells and address decoder, are addressed through a dedicated software test that checks the memory cell contents versus the expected value, using signature-based techniques.

  • Page 19: Table 16. Flash_Sm_2

    UM1845 Description of hardware and software diagnostics SM CODE FLASH_SM_1 Periodicity Continuous Test for the diagnostic Multiple faults protection CPU_SM_0: periodical core self-test software Recommendations and known limitations CPU_SM_1 correct implementation supersede this requirement Table 16. FLASH_SM_2 SM CODE FLASH_SM_2 ®...

  • Page 20: Table 18. Flash_Sm_4

    UM1845 Description of hardware and software diagnostics Table 18. FLASH_SM_4 SM CODE FLASH_SM_4 Description Static data encapsulation Ownership End user If static data are stored in Flash memory, encapsulation by a checksum field with encoding capability (like CRC) must be implemented. Detailed implementation Checksum validity is checked by application software before static data consuming Error reporting...

  • Page 21: Table 21. Flash_Sm_8

    Recommendations and known marginal failure modes, mainly affecting program counter and Flash interface functions. The limitations associated diagnostic coverage is therefore expected to be not relevant in the framework of STM32F2 Series safety concept UM1845 - Rev 4 page 21/108...

  • Page 22: Embedded Sram

    Periodical software test for SRAM memory Ownership End user or ST To enhance the coverage on SRAM data cells and to ensure adequate coverage for permanent faults affecting the address decoder it is required to execute a periodical software test on the system RAM Detailed implementation memory.

  • Page 23: Table 24. Ram_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE RAM_SM_2 Multiple faults protection Refer to CPU_SM_4 Recommendations and known limitations Refer to CPU_SM_4 Table 24. RAM_SM_3 SM CODE RAM_SM_3 Description Information redundancy for safety-related variables in application software Ownership End user To address transient faults affecting SRAM controller, it is required to implement information redundancy on the safety-related system variables stored in the RAM.

  • Page 24: Table 26. Ram_Sm_5

    UM1845 Description of hardware and software diagnostics SM CODE RAM_SM_4 Test for the diagnostic Multiple faults protection CPU_SM_0: periodical core self-test software Needed just in case of application software execution from SRAM. Recommendations and known limitations CPU_SM_1 correct implementation supersedes this requirement Table 26.

  • Page 25: System Bus Architecture

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

  • Page 26: Table 29. Lock_Sm_0

    Description Lock mechanism for configuration options Ownership The STM32F2 Series MCUs feature spread protection to prevent unintended configuration changes for some peripherals and system registers (for example PVD_LOCK, timers); the spread protection Detailed implementation detects systematic faults in software application. The use of this method is encouraged to enhance...

  • Page 27: Exti Controller

    UM1845 Description of hardware and software diagnostics 3.6.5 EXTI controller Table 30. NVIC_SM_0 SM CODE NVIC_SM_0 Description Periodical read-back of configuration registers Ownership End user This test is implemented by executing a periodical check of the configuration registers for a system peripheral against its expected value.
  • Page 28 UM1845 Description of hardware and software diagnostics SM CODE NVIC_SM_1 According to IEC 61508:2 Table A.1 recommendations, a diagnostic measure for continuous, absence or cross-over of interrupt must be implemented. The method of expected and unexpected interrupt check is implemented at application software level. The guidelines for the implementation of the method are the following: •...

  • Page 29: Direct Memory Access Controller (Dma)

    UM1845 Description of hardware and software diagnostics 3.6.6 Direct memory access controller (DMA) Table 32. DMA_SM_0 SM CODE DMA_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to DMA configuration register and channel addresses register as well. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5...

  • Page 30: Table 34. Dma_Sm_2

    UM1845 Description of hardware and software diagnostics Table 34. DMA_SM_2 SM CODE DMA_SM_2 Description Information redundancy including sender or receiver identifier on data packet transferred via DMA Ownership End user This method helps to identify inside the MCU the source and the originator of the message exchanged by DMA.

  • Page 31: Table 36. Dma_Sm_4

    UM1845 Description of hardware and software diagnostics SM CODE DMA_SM_3 Recommendations and known None limitations Table 36. DMA_SM_4 SM CODE DMA_SM_4 Description DMA transaction awareness Ownership End user DMA transactions are non-deterministic by nature, because typically driven by external events like communication messages reception.

  • Page 32: Controller Area Network (Can)

    UM1845 Description of hardware and software diagnostics 3.6.7 Controller area network (CAN) Table 37. CAN_SM_0 SM CODE CAN_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to CAN configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...
  • Page 33 UM1845 Description of hardware and software diagnostics SM CODE CAN_SM_2 This method aims to protect the communication between a peripheral and his external counterpart establishing a kind of “protected” channel. The aim is to specifically address communication failure modes as reported in IEC61508:2, 7.4.11.1.

  • Page 34: Universal Asynchronous Receiver/Transmitter (Uart)

    UM1845 Description of hardware and software diagnostics 3.6.8 Universal asynchronous receiver/transmitter (UART) Table 40. UART_SM_0 SM CODE UART_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to UART configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 35: Table 43. Uart_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE UART_SM_2 Ownership End user This method is implemented adding to data packets transferred by UART a redundancy check (like a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust Detailed implementation enough to guarantee at least 90% probability of detection for a single bit flip in the data packet.

  • Page 36: Inter-Integrated Circuit (I2C) 1/2

    UM1845 Description of hardware and software diagnostics 3.6.9 Inter-integrated circuit (I2C) 1/2 Table 44. IIC_SM_0 SM CODE IIC_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to I2C configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 37: Table 47. Iic_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE IIC_SM_2 This method is implemented adding to data packets transferred by I2C a redundancy check (like a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust Detailed implementation enough to guarantee at least 90% probability of detection for a single bit flip in the data packet.
  • Page 38 UM1845 Description of hardware and software diagnostics SM CODE IIC_SM_4 Error reporting Refer to CAN_SM_2 Fault detection time Refer to CAN_SM_2 Addressed fault model Refer to CAN_SM_2 Dependency on MCU configuration Refer to CAN_SM_2 Initialization Refer to CAN_SM_2 Periodicity Refer to CAN_SM_2 Test for the diagnostic Refer to CAN_SM_2 Multiple faults protection...

  • Page 39: Serial Peripheral Interface (Spi) 1/2

    UM1845 Description of hardware and software diagnostics 3.6.10 Serial peripheral interface (SPI) 1/2 Table 49. SPI_SM_0 SM CODE SPI_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to SPI configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 40: Table 52. Spi_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE SPI_SM_2 This method is implemented adding to data packets transferred by SPI a redundancy check (like a CRC check, or similar one) with encoding capability. The checksum encoding capability must be robust Detailed implementation enough to guarantee at least 90% probability of detection for a single bit flip in the data packet.
  • Page 41 UM1845 Description of hardware and software diagnostics SM CODE SPI_SM_4 Error reporting Refer to CAN_SM_2 Fault detection time Refer to CAN_SM_2 Addressed fault model Refer to CAN_SM_2 Dependency on MCU configuration Refer to CAN_SM_2 Initialization Refer to CAN_SM_2 Periodicity Refer to CAN_SM_2 Test for the diagnostic Refer to CAN_SM_2 Multiple faults protection...

  • Page 42: Usb Hs/Fs

    Test for the diagnostic Not needed Multiple faults protection USB_SM_2: Information redundancy techniques on messages Recommendations and known limitations None Table 56. USB_SM_2 SM CODE USB_SM_2 Description Information redundancy techniques on messages Ownership ST or end user UM1845 - Rev 4 page 42/108...

  • Page 43: Table 57. Usb_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE USB_SM_2 The implementation of required information redundancy on messages, USB communication module Detailed implementation is fitted by hardware capability. It basically allows to activate the automatic insertion (and check) of CRC checksums to packet data. Error reporting Error flag raise and optional Interrupt Event generation Fault detection time...

  • Page 44: Analog-To-Digital Converters (Adc)

    UM1845 Description of hardware and software diagnostics 3.6.12 Analog-to-digital converters (ADC) Table 58. ADC_SM_0 SM CODE ADC_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to ADC configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 45: Table 61. Adc_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE ADC_SM_2 The guidelines for the implementation of the method are the following: • The expected range of the data to be acquired are investigated and adequately documented. Note that in a well-designed application it is improbable that during normal operation an input signal has a very near or over the upper and lower rail limit (saturation in signal acquisition).

  • Page 46: Table 62. Adc_Sm_4

    UM1845 Description of hardware and software diagnostics Table 62. ADC_SM_4 SM CODE ADC_SM_4 Description 1oo2 scheme for ADC inputs Ownership End user This safety mechanism is implemented using two different SAR ADC channels to acquire the same input signal. The application software checks the coherence between the two readings. Detailed implementation It is recommended to use two different ADC modules belonging to different ADC modules Error reporting...

  • Page 47: Digital-To-Analog Converter (Dac)

    UM1845 Description of hardware and software diagnostics 3.6.13 Digital-to-analog converter (DAC) Table 63. DAC_SM_0 SM CODE DAC_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to DAC configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 48: Basic Timers Tim 6/7

    UM1845 Description of hardware and software diagnostics 3.6.14 Basic timers TIM 6/7 Table 65. GTIM_SM_0 SM CODE GTIM_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to general purpose counter timer TIM6 or TIM7 configuration registers.

  • Page 49: Advanced, General And Low-Power Timers Tim1/2/3/4/5/8/9/10/11/12/13/14

    UM1845 Description of hardware and software diagnostics 3.6.15 Advanced, general and low-power timers TIM1/2/3/4/5/8/9/10/11/12/13/14 Note: As the timers are equipped with many different channels, each independent from the others, and possibly programmed to realize different features, the safety mechanism is selected individually for each channel. Table 67.

  • Page 50: Table 69. Atim_Sm_2

    UM1845 Description of hardware and software diagnostics SM CODE ATIM_SM_1 Tolerance implementation in timer checks is recommended to avoid false positive outcomes of the Recommendations and known diagnostic. limitations This method apply to timer channels merely used as elapsed time counters Table 69.

  • Page 51: Table 71. Atim_Sm_4

    UM1845 Description of hardware and software diagnostics SM CODE ATIM_SM_3 Initialization Depends on implementation Periodicity Continuous Test for the diagnostic Not needed Multiple faults protection CPU_SM_0: periodical core self-test software Efficiency versus transient failures is linked to final application characteristics. We define as Tm the Recommendations and known minimum duration of PWM wrong signal permanence (wrong frequency, wrong duty, or both) required to limitations...

  • Page 52: General-Purpose Input/Output (Gpio) - Port A/B/C/D/E/F/G/H/I

    UM1845 Description of hardware and software diagnostics 3.6.16 General-purpose input/output (GPIO) - port A/B/C/D/E/F/G/H/I Table 72. GPIO_SM_0 SM CODE GPIO_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to GPIO configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting...

  • Page 53: Table 75. Gpio_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE GPIO_SM_2 Ownership End user This method addresses GPIO lines used as outputs. Implementation is done by a loopback scheme, connecting the output to a different GPIO line programmed as input and by using the input line to check Detailed implementation the expected value on output port.

  • Page 54: Real-Time Clock Module (Rtc)

    UM1845 Description of hardware and software diagnostics 3.6.17 Real-time clock module (RTC) Table 76. RTC_SM_0 SM CODE RTC_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to RTC configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 55: Table 78. Rtc_Sm_2

    UM1845 Description of hardware and software diagnostics Table 78. RTC_SM_2 SM CODE RTC_SM_2 Description Information redundancy on backup registers Ownership End user Data stored in RTC backup registers must be protected by a checksum with encoding capability (for instance, CRC). Checksum must be checked by application software before consuming stored Detailed implementation data.

  • Page 56: Power Control

    VDD, allowing to use PVD and PVM to control high and low Recommendations and known thresholds for VDD). limitations Internal monitoring PVD has limited capability to address failures affecting STM32F2 Series internal voltage regulator. Refer to device FMEA for details UM1845 - Rev 4 page 56/108...

  • Page 57: Table 82. Vsup_Sm_2

    UM1845 Description of hardware and software diagnostics Table 82. VSUP_SM_2 SM CODE VSUP_SM_2 Description Independent watchdog Ownership The independent watchdog is fed directly by VDD; therefore, major failures in the power supplies Detailed implementation for digital logic (core or peripherals) does not affect its behavior but may lead to a violation of the IDWG timeout Error reporting Reset signal generation...
  • Page 58 UM1845 Description of hardware and software diagnostics SM CODE VSUP_SM_4 Error reporting Interrupt generation on specific EXTI lines Fault detection time Depends on threshold programming, refer to functional documentation Addressed fault model Permanent and Transient Dependency on MCU configuration None Initialization Protection enable and threshold programming on selected power rails in Power control register Periodicity...

  • Page 59: Reset And Clock Control (Rcc) Subsystem

    UM1845 Description of hardware and software diagnostics 3.6.19 Reset and clock control (RCC) subsystem Table 85. CLK_SM_0 SM CODE CLK_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to configuration registers for clock and reset system (refer to RCC register map).

  • Page 60: Table 88. Clk_Sm_3

    UM1845 Description of hardware and software diagnostics SM CODE CLK_SM_2 Ownership The independent watchdog IWDG is able to detect failures in internal main MCU clock (lower Detailed implementation frequency) Error reporting Reset signal generation Fault detection time Depends on implementation (watchdog timeout interval) Addressed fault model Permanent Dependency on MCU configuration...

  • Page 61: Independent Watchdog (Iwdg), System Window Watchdog (Wwdg)

    UM1845 Description of hardware and software diagnostics 3.6.20 Independent watchdog (IWDG), system window watchdog (WWDG) Table 89. WDG_SM_0 SM CODE WDG_SM_0 Description Periodical read-back of configuration registers Ownership End user This method must be applied to WDG or WDG configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5...

  • Page 62: Debug

    UM1845 Description of hardware and software diagnostics 3.6.21 Debug Table 91. DBG_SM_0 SM CODE DBG_SM_0 Description Independent watchdog Ownership The debug unintentional activation due to hardware random fault results in the massive disturbance Detailed implementation of CPU operations, leading to intervention of the independent watchdog or alternately, the other system watchdog WWGDG or an external one Error reporting Reset signal generation...

  • Page 63: Cyclic Redundancy-Check Module (Crc)

    UM1845 Description of hardware and software diagnostics 3.6.22 Cyclic redundancy-check module (CRC) Table 92. CRC_SM_0 SM CODE CRC_SM_0 Description CRC self-coverage Ownership The CRC algorithm implemented in this module (CRC-32 Ethernet polynomial: 0x4C11DB7) offers excellent features in terms of error detection in the message. Therefore permanent and transient Detailed implementation faults affecting CRC computations are easily detected by any operations using the module to recompute an expected signature...

  • Page 64: System Configuration Controller (Syscfg)

    Ownership End user In STM32F2 Series several hardware-based efficient safety mechanisms (e.g. ECC on Flash) are available. This method shall be applied to any configuration register related to diagnostic measure operations, including error reporting. End user shall therefore individuate configuration registers...

  • Page 65: Ethernet (Eth): Media Access Control (Mac) With Dma Controller

    UM1845 Description of hardware and software diagnostics 3.6.24 Ethernet (ETH): media access control (MAC) with DMA controller Table 95. ETH_SM_0 SM CODE ETH_SM_0 Description Periodical read-back of Ethernet configuration registers Ownership End user This method must be applied to Ethernet configuration registers (including those relate to unused Detailed implementation module features).
  • Page 66 UM1845 Description of hardware and software diagnostics SM CODE ETH_SM_2 This method aim to protect the communication between a peripheral and its external counterpart. It is used in Ethernet local safety concept to address failures not detected by ETH_SM_1 and to Detailed implementation increase its associated diagnostic coverage.

  • Page 67: Flexible Static Memory Controller (Fsmc)

    UM1845 Description of hardware and software diagnostics 3.6.25 Flexible static memory controller (FSMC) Table 98. FSMC_SM_0 SM CODE FSMC_SM_0 Description Control flow monitoring in application software Ownership End user If FSMC is used to connect an external memory containing software code to be executed by the CPU, permanent and transient faults affecting the FSMC memory controller are able to interfere with the access operation by the CPU, leading to wrong data or instruction fetches.

  • Page 68: Table 100. Fsmc_Sm_2

    This method has negligible efficiency in detecting hardware random failures affecting the FSMC Recommendations and known interface. It can be part of End user safety concept because addressing memories outside limitations STM32F2 Series MCU UM1845 - Rev 4 page 68/108...

  • Page 69: Serial Audio Interface (Sai)

    UM1845 Description of hardware and software diagnostics 3.6.26 Serial audio interface (SAI) Table 102. SAI_SM_0 SM CODE SAI_SM_0 Description Periodical read-back of SAI configuration registers Ownership End user This method must be applied to SAI configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...
  • Page 70 UM1845 Description of hardware and software diagnostics SM CODE SAI_SM_2 Ownership End user This safety mechanism is implemented using the two SAI interfaces to decode/receive the same Detailed implementation input stream audio. The application software checks the coherence between the received data Error reporting Depends on implementation Fault detection time...

  • Page 71: True Random Number Generator (Rng)

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

  • Page 72: Advanced Encryption Standard Hardware Accelerator (Aes)

    UM1845 Description of hardware and software diagnostics 3.6.28 Advanced encryption standard hardware accelerator (AES) Table 107. AES_SM_0 SM CODE AES_SM_0 Description Periodical read-back of AES configuration registers Ownership End user This method must be applied to AES configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting...
  • Page 73 UM1845 Description of hardware and software diagnostics SM CODE AES_SM_2 This method aim to protect the communication between a peripheral and his external counterpart. It is used in AES local safety concept to address failures not detected by the encryption/decryption Detailed implementation features.

  • Page 74: Hash Processor (Hash)

    UM1845 Description of hardware and software diagnostics 3.6.29 HASH processor (HASH) Table 110. HASH_SM_0 SM CODE HASH_SM_0 Description Periodical read-back of HASH configuration registers Ownership End user This method must be applied to HASH configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 75: Digital Camera Interface (Dcmi)

    UM1845 Description of hardware and software diagnostics 3.6.30 Digital camera interface (DCMI) Table 112. DCMI_SM_0 SM CODE DCMI_SM_0 Description Periodical read-back of DCMI configuration registers Ownership End user This method must be applied to DCMI configuration registers. Detailed implementation Detailed information on the implementation of this method can be found in Section 3.6.5 Error reporting Refer to NVIC_SM_0...

  • Page 76: Disable And Periodic Cross-Check Of Unintentional Activation Of Unused Peripherals

    UM1845 Description of hardware and software diagnostics 3.6.31 Disable and periodic cross-check of unintentional activation of unused peripherals This section reports the safety mechanism that addresses peripherals not used by the safety application, or not used at all. Table 114. FFI_SM_0 SM CODE FFI_SM_0...

  • Page 77: Conditions Of Use

    + = Recommended as additional safety measure, but not considered in this Safety Manual for the computation of safety metrics. STM32F2 Series users can skip the implementation in case it is in contradiction with functional requirements or overlapped by another mechanism marked as “++”.
  • Page 78 UM1845 Conditions of use STM32F2 Series function Diagnostic Description Rank Perm Trans RAM_SM_0 Periodical software test for SRAM memory RAM_SM_2 Stack hardening for application software Information redundancy for system variables in RAM_SM_3 Embedded SRAM application software RAM_SM_4 Control flow monitoring in application software...
  • Page 79 UM1845 Conditions of use STM32F2 Series function Diagnostic Description Rank Perm Trans USB_SM_0 Periodical read-back of configuration registers USB_SM_1 Protocol error signals USB HS/FS USB_SM_2 Information redundancy techniques on messages Information redundancy techniques on messages, USB_SM_3 including end-to-end safing ADC_SM_0...
  • Page 80 ® CoU_1 Cortex -M3 CPU must be compatible as valid safe state at system level STM32F2 Series debug features must not be used Debug CoU_2 in safety function(s) implementation Low power mode state must not be used in safety ®...
  • Page 81 Because these modules are used by every end user application, related methods or safety mechanism are mainly conceived to be application-independent. For STM32F2 Series microcontroller system critical modules are: CPU, Reset, Power, Clocks, Busmatrixs and Interconnect, Flash and RAM memories (including their interfaces) •...

  • Page 82: Safety Results

    Safety results Safety results This section reports the results of the safety analysis of the STM32F2 Series MCUs, according to IEC 61508 and to ST methodology flow, related to the hardware random and dependent failures. Random hardware failure safety results The analysis for random hardware failures of STM32F2 Series devices reported in this Safety Manual is executed according to ST methodology flow for safety analysis of semiconductor devices according IEC61508.

  • Page 83: General Requirements For Freedom From Interferences (Ffi)

    STM32F2 Series internal modules in case of internal failures (freedom from interferences, FFI). These precautions are integral part of the STM32F2 Series safety concept and they can play a relevant role when multiple microcontroller modules are declared as “non-safety related” by the end user as per Section 4.1.1...

  • Page 84: Dependent Failures Analysis

    As there are no on-chip redundancy on STM32F2 Series devices, the CCF quantification through the BetaIC computation method is not required. Note that in the case of 1oo2 safety architecture implementation, the end user is required to evaluate the parameter βD, which is the measure of the common-cause between the two...

  • Page 85: Internal Temperature

    UM1845 Dependent failures analysis 4.2.4 Internal temperature The abnormal increase of the internal temperature is a potential source of dependent failures, because it can affect many MCU parts and therefore lead to not-independent failures. The safety mechanism to be used to mitigate this potential effect is the following: •...

  • Page 86: List Of Evidences

    • Safety Case with the full list of all safety analysis related documents • ST internal FMEDA tool database for the computation of the safety metrics, including the estimated and measured values • Safety Report, the document that describes in detail the safety analysis executed on STM32F2 Series devices and the clause-by-clause compliance to IEC 61508 •...

  • Page 87: A Change Impact Analysis For Other Safety Standards

    The safety function is completely in the scope of the end user application. The STM32F2 Series MCUs with the adoption of safety mechanism described in this Safety Manual as single compliant item is by itself suitable for CM application up to PLd (equivalent to SIL2).
  • Page 88 UM1845 ISO 13849-1 / ISO 13849-2 Block Cat. Ref. § Summary Designated architecture of Logic diagram Enforcing category B requirements by adopting solutions based on “well tried components” for safety critical application and “well tried” safety Single channel architecture, one MCU in principles.

  • Page 89: Iso 13849 Safety Metrics Computation

    UM1845 ISO 13849-1 / ISO 13849-2 Figure 7. Block diagram for ISO 13849 Cat. 2 interconnecting means input device, e.g. sensor logic output device, e.g. main contactor monitoring test equipment output of TE Figure 8. Block diagram for ISO 13849 Cat. 3 and Cat. 4 interconnecting means cross monitoring I1, I2...

  • Page 90: Iso 13849 Work Products

    DC (ISO13849-2 Tab.D.21 no exclusion allowed) and this is the same assumption done in STM32F2 Series analysis in this Safety Manual. It is necessary to calculate the DC only for subsystem made of a 2 MCUs architecture by applying the formula:...
  • Page 91 Dated reference to this part of ISO 13849 (that is “ISO 13849-1:2006”); 11 Information for use Category (B, 1, 2, 3, or 4) STM32F2 Series Safety Manual Performance level (a, b, c, d, or e) Use of de-energization (see ISO 13849-2) G.2 Measures for the control of...

  • Page 92: Iec 62061:2005/Amd1:2012

    61508:2010 part 2, Route 1H, ref. to §7.4.4.2. Coming from the IEC 62061 definition §3.2.8, natively a microprocessor has to be considered as a complex component. For this reason, the results reported in this Safety Manual for the STM32F2 Series item (refer to Section 4 Safety results), in the scope of IEC 61508 are still applicable also in the machines context ruled by IEC 62061.

  • Page 93: Iec 62061 Architectural Categories

    The SRCF is completely in the scope of the end user. The STM32F2 Series device with the adoption of safety mechanism described in this Safety Manual as single compliant item is by itself suitable for applications up to SILCL 2.

  • Page 94: Iec 62061 Safety Metrics Computation

    1h, so PFHD = 1 / MTTF. Safety analysis executed for STM32F2 Series according IEC61508 is more and more accurate for the definition of dangerous failure identifications that can be re-mapped in IEC 62061 domain. Thus, values of λ and PFH that are...

  • Page 95: Iec 62061 Work Products

    End user responsibility Functional safety requirements specification for SRCFs 5.2.3 Safety integrity requirements specification for SRCFs 5.2.4 SRECS design 6.2.5 STM32F2 Series Safety Manual Structured design process 6.6.1.2 SRECS design documentation 6.6.1.8 End user responsibility Structure of function blocks 6.6.2.1.1 SRECS architecture 6.6.2.1.5...

  • Page 96: Iec 61800 Architectural Categories

    Hardware design on an architectural level Software design on an architectural level IEC 61508-3 Estimation of the probability of failure of safety functions due to random STM32F2 Series Safety Manual and IEC 61508-2 hardware failures on a level of functional block diagrams FMEDA Reviews of system design Detailed planning of the validation of safety related PDS(SR).

  • Page 97: Iso 26262:2010

    UM1845 ISO 26262:2010 IEC 618000 5.2 STM32F2 Series IEC 61800-5.2 Part- IEC 61508 document Information to be provided Clause Reviews of the system design Functional tests on module level Integration and test of the safety related PDS(SR). Review of HW or SW integration test results and documentation Develop user documentation describing PDS(SR) installation, commissioning, operation and maintenance.

  • Page 98: Iso 26262 Safety Metrics Computation

    FTTI. For the STM32F2 Series devices, the fulfillment of ASIL B latent faults metrics (60%) is achievable with the adoption of the same safety mechanism combination that guarantees the microcontroller to be suitable for SIL2 applications.
  • Page 99 Information to be provided Clause STM32F2 Series Safety Manual, FMEA and Results of safety analyses 9-8.5.1 FMEDA Note: STM32F2 Series FMEA should be reworked in order to map IEC61508 reference failure modes into ISO26262 ones. UM1845 - Rev 4 page 99/108...

  • Page 100: Revision History

    Figure 1. STMicroelectronics product development process 30-Jan-2015 Updated Block diagram for IEC 62061 Cat. B figure. Updated Block diagram for IEC 62061 Cat. D figure. 21-Dec-2017 Changed the document scope from public to ST Restricted. Updated introduction. Updated Table 1. Terms and abbreviations.

  • Page 101: Table Of Contents

    Reference normative ............3 STM32F2 Series microcontroller development process ......5 STMicroelectronics standard development process .
  • Page 102 UM1845 Contents 3.6.13 Digital-to-analog converter (DAC) ......... . . 47 3.6.14 Basic timers TIM 6/7 .
  • Page 103 UM1845 Contents ISO 13849-1 / ISO 13849-2 ........... . . 87 A.1.1 ISO 13849 architectural categories .

  • Page 104: List Of Tables

    UM1845 List of tables List of tables Table 1. Terms and abbreviations ............. . . 2 Table 2.
  • Page 105 UM1845 List of tables Table 53. SPI_SM_4 ............... 40 Table 54.
  • Page 106 UM1845 List of tables Table 107. AES_SM_0 ............... 72 Table 108.

  • Page 107: List Of Figures

    UM1845 List of figures List of figures Figure 1. STMicroelectronics product development process ..........6 Figure 2.
  • Page 108 ST’s terms and conditions of sale in place at the time of order acknowledgement. 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’...

Table of Contents