What is the cause of erratum "2.10.6 Wrong ADC result if conversion done late after calibration or previous conversion"?
I have a mature project utilizing the STM32L4R5xxx series. The main function uses uC's ADC over about 15 channels. As a rule, the ADC readings are taken at a slow rate -- some triggered every 100 ms, others triggered every 5 seconds, and other triggered every minute.
By and large the readings we get look good. However, our error rates are a little higher than we'd like. While deep reviewing everything about the project, from circuit diagrams, to chip datasheets, firmware implementation, HAL libraries, and the uC documents, we discovered that the STM32L4Rxxx errata (en.DM00371862-STM32L4_errata.pdf) mentions this under 2.10.6:
-----
Wrong ADC result if conversion done late after calibration or previous conversion
Description
The result of an ADC conversion done more than 1 ms later than the previous ADC conversion or ADC calibration might be incorrect.
Workaround
Perform two consecutive ADC conversions in single, scan or continuous mode. Reject the result of the first conversion and only keep the result of the second.
-----
From my reading, we should be getting a "wrong ADC result" every time, since we never take an ADC reading faster than 100ms at a time. The description though does say "might be incorrect".
So maybe some understanding of the mechanism of this erratum would be helpful.
- What is the mechanism behind this erratum?
- What makes it 1 ms that causes the issue? Some kind of RC decay?
- How often is "might be incorrect"? Close to 100 % of the time, or 0.001% of the time, or somewhere in between?
- How is the value typically incorrect? Is it a little lower than it should be, or cut in half, or close to zero, or something else in between?
I'm trying to reduce risk at this stage of the project -- though we only take readings every 100 ms, taking a reading exactly at the 100 ms mark is very important to the core function of the device. I can't introduce such a change suggested in the workaround without knowing some specifics of how critical the "might be incorrect" is.
Also, from my dive into the HAL and the STM32CubeMx, I don't see where it takes this into account. It makes me wonder then how critical of an issue this is.
