What is the cause of erratum "2.10.6 Wrong ADC result if conversion done late after calibration or previous conversion"?

[DDrin.1]

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.

[DDrin.1]

Note that, before asking my question, I searched the forum and found these two unanswered questions from 2020:

• https://community.st.com/s/question/0D53W000000ZVTuSAO/errata-sheet-workaround-for-wrong-adc-result-done-late-after-calibration-or-previous-conversion
• https://community.st.com/s/question/0D53W00000KopjsSAB/stm32g4-adc-errata

[Simon V. · Accepted solution]

Hello,

1/ During ADC circuity simulations and characterization, we observed that silicon corner process showing very few additional leakage when acquisition are separed by more than 1ms, in this case the ADC sampling circuitry may create additional error (mostly offset and gain error) compared to specification data.

2/To reduce the ADC power consumption, some internal current biasing sources are hold after hundred of microseconds when acquisition is completed.

3,4/ The limitation occurrence is relative to process design natural variability in silicon corner cases. The error is not relative to channels level or supply voltage in final customer application. To achieve the highest ADC performances with all samples when acquisition rate is very low, we recommend to reject first acquisition sample.

Let me know if you need further information

Regards,

Simon

[jminack]

Thanks for your response Simon.

Could you please clarify the following about the first, dummy conversion, as it is not stated explicitly in the errata:

1) Should the sampling time of the dummy conversion match the sampling time of the second, or can it be shortened?

2) Does the dummy conversion have to be from the same acquisition channel?

[GLASS]

Hi, we need to convert one ADC sample HW triggered from random external event (0.1 Hz to 100Khz occurence).

So stm32l4 errata workaround is not usuable for us.

@Simon V., please can you confirm that stm32u575 with lqfp64 package don't exhibit the same issue that stm32l4r...?

[Simon V.]

Hello,

To answer your question #1 and #2, there is no specified information in the errata sheet because the dummy conversion can be done on any channel with any sampling time configuration : just any dummy conversion is sufficient to recover the issue.

Regards,

Simon

[Simon V.]

Hello,

You can refer to ES0499 - Rev 8 which is the errata sheet document of STM32U575x for ADC limitations

I confirm the STM32U575X is not concerned by the mentioned STM32L4 ADC limitation.

Regards,

Simon

[gbm]

In that case I would use continuous conversion with DMA and read the result from memory when the event occurs.