In actual end-user applications, not all the STM32F2 Series parts or modules are used for the implementation of
the safety function. That can happens under two possible alternative conditions:
•
The part is not used at all (disabled).
•
The part is used for the implementation of a function that is non-safety related (for example a GPIO line
driving a "power-on" signaling led on an electronic board).
Requiring the implementation of the respective safety mechanism for those unused parts could result in an
overkill. The safety analysis results can be therefore customized.
The end user can define the selected STM32F2 Series parts as "non-safety related" under the following
conditions (end user responsibility):
•
Collect rationales and evidences that the parts play no role in safety function implementation.
•
Collect rationales and evidences that the parts do not interfere with the safety function during normal
operation due to final system design decisions.
•
Fulfill the below-reported general condition for the mitigation of the intra-MCU interferences
of general requirements for
The end user is therefore allowed for "non-safety related" parts to do the following:
•
Discard the part contribution from metrics computations in FMEDA;
•
Do not implement the related safety mechanisms listed in Table 1.
With regard to SFF computation, this procedure is equivalent to declare "no part/no effect" as per IEC61508-4,
3.6.13 or 14 definition any failure of discarded modules.
4.1.2
General requirements for freedom from interferences (FFI)
A dedicated analysis has highlighted a list of general requirements to be followed in order to mitigate potential
interferences between 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
The requirement for the end user is to implement the safety mechanism listed in
requirements for FFI
despite any evaluation about their contribution for the safety metrics computations.
Diagnostic
FFI_SM_0
FFI_SM_1
BUS_SM_0
NVIC_SM_0
NVIC_SM_1
DMA_SM_0
DMA_SM_2
DMA_SM_4
GPIO_SM_0
1. To be implemented only if DMA is actually used
4.1.3
Notes on multiple faults scenario
In principle, IEC61508 requires to analyze multiple faults scenarios, therefore restrictions to one fault at time
conditions could be not acceptable. Accordingly, the safety analysis for STM32F2 Series took into consideration
also multiple faults scenarios. Furthermore, following the spirit of ISO26262 (the reference and state-of-art
standard norm for integrated circuit safety analysis) the analysis investigated faults able to "disable" each safety
mechanism, in order to individuate mitigation measure for such condition.
UM1845 - Rev 4
FFI).
(implementation details can be found in Description of hardware and software diagnostics )
Table 118.
Description
Unused peripheral disable
Periodical read-back of interference avoidance registers
Periodical software test for interconnections
Periodical read-back of configuration registers
Expected and unexpected interrupt check by application software
Periodical read-back of configuration registers
Information redundancy including sender or receiver identifier on data packet transferred via DMA
(1)
DMA transactions awareness
Periodical read-back of configuration registers
List of general requirements for FFI
Random hardware failure safety results
(Table 118. List
Section 4.1.1
Table 118. List of general
Section 3.6
tables report on the
UM1845
.
(1)
page 83/108
Need help?
Do you have a question about the STM32F2 Series and is the answer not in the manual?
Questions and answers