Errata Sheet: Workaround for wrong ADC result done late after calibration or previous conversion

[AbidSulaiman]

According to the STM32L433xx/443xx device errata, the result of an ADC conversion done more than 1 ms later than ADC calibration or previous ADC conversion might be incorrect.

The workaround suggested by the errata sheet is, "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."

In my case, i want to sample at maximum sampling time, which is 640.5 cycles. If extra measurement needs to be done, i would like to sample another channel at 2.5 cycles to reduce time active duration time.

From my understanding, my approach could work since the ADC channels share a sample and hold circuit. However, if the time for the ADC channel switching is longer than 1 ms, the result might still be incorrect.

Since there is no data on the channel switching time, i am unsure if my approach works.

I am very grateful for your help on this topic. Thank you very much.

TLDR:

My question is that:

1. Is the consecutive conversions needs to be from same ADC channel? Can different channel is measured for the extra conversion?
2. How about the channel switching time. Is it longer than 1 ms?

[AMurz.1]

I second this question to see if these STM32 parts are viable with very low speeds.

According to the datasheet, the channel switching time might be negligible, but the sampling time can be set above 1ms, in which case the errata may be triggered, meaning all ADC conversions would be wrong if the sampling time is above 1ms ...

[DDrin.1]

The STM32L4Rxxx and STM32L4Sxxx errata list the same thing under 2.10.6.

>> The result of an ADC conversion done more than 1 ms later than the previous ADC conversion or ADC calibration might be incorrect.

I find the erratum description to be really lacking. As written, with no understanding of why this erratum occurs, it implies to me that the ADC function for the STM32L4R and STM32L4S series is critically broken and can't be trusted.

But from experience I know that it works the vast majority of the time. How often then is "might be incorrect"?

If this is the case, why doesn't the HAL library take it into account? Afterall, that is one of the selling points of using the HAL, is that if anyone should know about the errata and how to handle it -- it should be the chip makers. Thus rely on their HAL to take it into account. But from my dive into the HAL at a recent release, the HAL does not take this ADC erratum into account.

[JEsko]

Has there been a root cause found within the ADC itself that is the reason why these work arounds such as taking multiple readings within a given time (1mS) are required? Is it known if the severity of the issue is dependent on temperature or ADC operating voltage? Thanks to anyone who has had experience with this issue and can add info on work arounds that helped.