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

[Felix Sammer]

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]

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]

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]

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?

[waclawek.jan]

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]

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]

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

[Felix Sammer]

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]

Posted on January 24, 2018 at 10:11

decoupling of VDDA:

[waclawek.jan]

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

[Felix Sammer]

Posted on January 26, 2018 at 09:16

Thanks for the feedback, much appreciated.

I still tend to believe that the problem is related to the conversion period and not the sampling period of the ADC peripheral. Probably I did not make it clear enough in my previous posts. But running the ADC at full speed (80MHz) and varying the sample time (tried various 2.5 clk cycles, 6.5, 47.5 etc) did not made any difference. Issue was always present. But once I set the ADC clk prescaler to 2 (ADC running with 40MHz) the issue was gone, independent from the sample time setting.

I think these observations point out that during sample period the sample cap is always getting sufficiently charged no matter the selected sample time (thus no influence from outside causing this issue). But the successive approximation register seems to have struggle to perform at full speed, I think also the fact that the inaccuracy happens right at VREF/2 points into the direction of the successive approximation mechanism.

@JW: ADC1 handles 4 fast channels, 80Mhz, sample time 2.5 clk cycles, ADC2 handles 9 slow channels, 80Mhz, sample time 6.5 clk cycles, have seen the 'issue' on both (fast and slow).

Things I can still check:

- If the clk source has any influence.

Felix

[waclawek.jan]

Posted on January 26, 2018 at 10:02

 ,

 ,

I'd like you also to reiterate things I've written at

https://community.st.com/0D70X000006Sw0iSAC

 ,

You may want to show us pictures of the layout to chew upon, and/or try experimenting with placement/values of th decoupling/filtering elements (placing caps closer to pins, using smaller value caps, replacing the 0.5Ohm series resistor by a small choke, etc.)

One more thing to consider is to use - at least for experiment - an externally generated reference voltage.

JW

[DWebb.2]

I had this exact issue with a Nucleo F446re evaluation board - the ADC would get 'stuck' around a halfway reading of 2048. As suggested above I changed the APB2 prescaler to 0b101 (AHB clock divided by 4) and this corrected the problem.

[neet_]

I want to know if you ultimately solved this problem, as I also encountered the same issue on L496. Even I I lowered the frequency of the ADC to 20M, but there is still this phenomenon.