STM32L4 ADC inaccuracy around VREF/2, ADC result gets 'stuck' at 2047

Felix Sammer · ‎2018-01-13

Posted on January 13, 2018 at 20:28

I am experiencing ADC inaccuracy around VREF/2 with the STM32L4. Measurement result gets 'stuck' at 2047 for a couple resolution steps, although signal that is measured increases further. At around approx. 2065 and upwards the ADC samples correctly again.

I already stripped down my code to exclude any influences from other peripherals (using ADC1 and ADC2 with multiple channels in DMA mode in original project) but even if I basically only initialize ADC2 and run it software trigger mode, sampling only one channel and increased sample time (47,5 cycles) I can still observe this phenomena. Checking in debug mode as well, looking right at the ADC2->DR register.

main:

HAL_ADCEx_Calibration_Start(&hadc2, ADC_SINGLE_ENDED);

for(;;) {

HAL_ADC_Start(&hadc2);

if(HAL_ADC_PollForConversion(&hadc2, 1000) == HAL_OK) {

ADC2Result = HAL_ADC_GetValue(&hadc2);

}

Anybody out there that can help me with this or have experienced this issue as well?

One more thing I have in mind I could do to verify this problem is to apply a function generator to the ADC and slowly step through measurement range of the ADC and at the same time dump the ADC result via the internal DAC and plot this with the function generator signal on a scope and see if the signal match.

Regards Felix

T J · ‎2018-01-14

Posted on January 14, 2018 at 22:05

the input stage for these chips is not the best,

but if you buffer your signal through an opamp, or at least have a bypass cap.

you may find this issue will go away.

you can't use any ground point to read the voltage.

use the VSSA ground pin on your voltimeter, and check the actual voltage on the input pin.

Felix Sammer · ‎2018-01-14

Posted on January 15, 2018 at 08:56

Thanks for the feedback I will try to make time today to measure signal on the PIN properly.

I added a picture of the ADC circuit, as you can see an opamp is already in place.

Felix Sammer · ‎2018-01-15

Posted on January 15, 2018 at 12:19

OK I measured with a multimeter (calibrated Fluke 187 0.1mV resolution) over C83 (to VSSA). VREF I set to 2.5V. Here is what I observe:

V_C83 < 1.250V: ADC results increase smoothly according to the applied voltage

1.250V < V_C83 < 1.254V: ADC returns always 2047

1.254V < V_C83 < 1.267V: ADC results fluctuate between 2047 and correct value

V_C83 > 1.267V: ADC results increase smoothly according to applied voltage

I tend to conclude this is a issue caused by internal ADC of the STM32L4.

Can anyone from the ST team maybe comment on my observations?

Felix Sammer · ‎2018-01-15

Posted on January 15, 2018 at 12:31

Hm, I guess it does has something to do with the sampling speed and/or ADC clock. Forgot to mention earlier that I run the ADC ad full speed (80MHz) while doing this increasing the sample time did not had any impact on my observations.

Now I changed the clock prescaler to factor 10 and it seems like the issue is gone now.

But for my purposes this is not really a solution, need to run the ADC at full speed since results get used for a fast control loop.

T J · ‎2018-01-15

Posted on January 16, 2018 at 00:06

Excellent news, I didn't know the ADs are touchy at 80MHz.

that's the full processor speed.

I guess if you need a high conversion rate you should be looking to flash converters and maybe FPGAs

or else move up to a STM32F7 series at 216MHz or the new STM32H runs at 400MHz

waclawek.jan · ‎2018-01-16

Posted on January 17, 2018 at 00:13

VREF I set to 2.5V

Is it stable enough/decoupled well enough to VREF-/VSSA? Tell us more details about the analog circuitry.

JW

Felix Sammer · ‎2018-01-24

Posted on January 24, 2018 at 09:54

Hi,

sorry for the late response, but the forum software seems to be kind of buggy. Every time I was logged into my account I could not reach this forum thread anymore.

Anyhow, the internal VREF from the micro controller is being used and its also being routed outside via the VREF pin where it is buffered and used for a couple measurements circuits as well (NTCs, current measurement offset).

Not sure if the issue is related to an unstable VREF, since I already have concluded that with lower ADC clock speed the problem disappears.

I just would appreciate if somebody (or ST) could confirm this issue in the ADC peripheral, then I can stop chasing ghosts.

And well cannot change to a different micro range (point of no return has been passed long time ago ). I can live with that issue, just was/still am curious what is causing this problem.

Felix

Felix Sammer · ‎2018-01-24

Posted on January 24, 2018 at 10:11

decoupling of VDDA:

waclawek.jan · ‎2018-01-24

Posted on January 24, 2018 at 20:33

Looks good.

At this point, I'd put in question the actual physical layout of all these elements.

And, instead of a multimeter, would recommend to employ a good-enough oscilloscope to observe the few-bin-equivalent voltage drops on the said pins (references, VDDA, ADC input; all properly referenced to VSSA *pin*) at the said frequencies (i.e. high tens of MHz), synced to the sampling process - which I am afraid is far from being trivial.

(ADC input at this point is perhaps less of a suspect as the problem is insensitive to sampling time, but there still may be a glitch/surge of increased consumption at the moment of sampling ends , or similar).

I don't say there's no problem in the internal circuitry of the chip, it's just usually so that in the vast majority of cases it's not. And as the problem is clock-dependent, I'd suspect frequency-dependent circuit elements first.

I just would appreciate if somebody (or ST) could confirm this issue in the ADC peripheral

I'm afraid you have to go to ST directly for such. There is negligible presence from ST's I wouldn't hold my breath, though.

JW