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

[Dvorak.Peter]

Posted on January 25, 2018 at 02:41

Felix, try reducing the ADC clock by 20 to 50%. The error is in the first cycle of the ADC conversion. It could be a slow ADC comparator or an internal RC node. Increasing the Vcc may help.

Peter

[waclawek.jan]

Posted on January 25, 2018 at 10:30

Peter,

According to the power supply decoupling picture from above, Felix runs VDD/VDDA at 3.3V already.

Lowering the clock might involve the SAI PLLs. Sounds like a fun project ;)

Felix,

Is this input one of the 'slow' or 'fast' ADC channels? Can you try another ADC input?

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.