ST STM32F2 Series - Table 61. ADC_SM_3

SM CODE ADC_SM_2
Detailed implementation
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).
• If the application software is aware of the state of the system, this information is to be used in the
range check implementation. For example, if the ADC value is the measurement of a current through a
power load, reading an abnormal value such as a current flowing in opposite direction versus the load
supply may indicate a fault in the acquisition module.
• As the ADC module is shared between different possible external sources, the combination of
plausibility checks on the different signals acquired can help to cover the whole input range in a very
efficient way
Error reporting Depends on implementation
Fault detection time Depends on implementation
Addressed fault model Permanent and Transient
Dependency on MCU
configuration
None
Initialization Depends on implementation
Periodicity Continuous
Test for the diagnostic Not needed
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known
limitations
The implementation (and the related diagnostic efficiency) of this safety mechanism are strongly application-
dependent
Table 61. ADC_SM_3
SM CODE ADC_SM_3
Description Periodical software test for ADC
Ownership End user
Detailed implementation
The method is implemented acquiring multiple signals and comparing the read value with the
expected one, supposed to be know. Method can be implemented with different level of complexity:
• Basic complexity: acquisition and check of upper or lower rails (VDD or VSS) and internal
reference voltage
• High complexity: in addition to basic complexity tests, acquisition of a DAC output connected
to ADC input and checking all voltage excursion and linearity
Error reporting Depends on implementation
Fault detection time Depends on implementation
Addressed fault model Permanent
Dependency on MCU configuration None
Initialization Depends on implementation
Periodicity Periodic
Test for the diagnostic Not needed
Multiple faults protection CPU_SM_0: periodical core self-test software
Recommendations and known
limitations
Combination of two different complexity method can be used to better optimize test frequency in
high demand safety functions
UM1845
Description of hardware and software diagnostics
UM1845 - Rev 4
page 45/108