Skip to main content
Associate
July 30, 2025
Solved

ADC readings 'sticking' anomaly

  • July 30, 2025
  • 6 replies
  • 641 views

I'm using the STM32H7B3.

ADC configuration:

 

Sahiel_1-1753879721438.png

Sample time : ~2us

LL_ADC_SAMPLINGTIME_64CYCLES_5  

Calibrations: 

HAL_ADCEx_LinearCalibration_FactorLoad(adc2)

HAL_ADCEx_Calibration_Start(adc2, ADC_CALIB_OFFSET, ADC_SINGLE_ENDED)

Observations:

Sahiel_2-1753881148542.png

The ADC counts seem to be stuck at values which are highlighted in the picture above at around 0.31 to 0.35 V and 0.62V to 0.66V

The ADC > DR also seems to be stuck and reads 255, 511 at the two voltage ranges mentioned above

Input signal source:

Sahiel_4-1753882434410.png

 

Analog Input voltage range is 0V - 5V in YELLOW converted to 3.3V scale which is also the Vref

Using only RED boxed channel that is connected to the ADC pin on the mcu 

Things that I tried:

  • Increasing the sample time to ~11us
  • Tried different calibration combinations HAL_ADCEx_Calibration_Start(adc2, ADC_CALIB_OFFSET_LINEARITY, ADC_SINGLE_ENDED)
  • Ignored the DMA buffer values and only observed the ADC > DR which also seems to directly jump from 255 to 288 and 511 to 544 

Nothing changes and it's repeatable 

Any suggestions would be helpful

Thank you!

 

 

Best answer by Sahiel

This issue was resolved when the F_adc which was 35Mhz was reduced to 6.25Mhz

6 replies

TDK
Super User
July 30, 2025

How is VREF+ connected? If you skip a cap here, or if it's unstable, you'll get readings like this.

"If you feel a post has answered your question, please click ""Accept as Solution""."
SahielAuthor
Associate
July 30, 2025

The Vref+ has a 1nF cap and it seems to be stable 

Sahiel_0-1753889013298.png

 

TDK
Super User
July 30, 2025

The recommendation is 1 uF + 100 nF. The 1 nF isn't doing much.

 

TDK_0-1753893299209.png

"If you feel a post has answered your question, please click ""Accept as Solution""."
MasterT
Lead II
July 30, 2025

There is a thread

https://community.st.com/t5/stm32-mcus-products/stm32h7-jumps-in-adc-transfer-curve-both-with-self-calibration/td-p/784260/page/2 

 My testing with H753 shows, that ADC in the H7 families sensitive to sequence of calibration.

Read Call. Factors // Write // Calibrate can't be called  "random", because some bits "latched" after action completed and uCPU has to be reset completely to re-initiate peripheral (ADC) status.

So, try  Not to  load Call. Factors before you start calibration. It doesn't make any sense since in normal circumstances calibration subroutine gonna to rewrite whatever pre-loaded.

Calibrations:

HAL_ADCEx_LinearCalibration_FactorLoad(adc2)

HAL_ADCEx_Calibration_Start(adc2, ADC_CALIB_OFFSET, ADC_SINGLE_ENDED)

SahielAuthor
Associate
July 31, 2025

Thank you for the suggestion I will not load the calibration factors as you mentioned.

Things that I have tried around calibration that did not resolve the above specific issue.

  • Used only HAL_ADCEx_Calibration_Start(adc2, ADC_CALIB_OFFSET, ADC_SINGLE_ENDED)
  • Used both 

    HAL_ADCEx_LinearCalibration_FactorLoad(adc2)

    HAL_ADCEx_Calibration_Start(adc2, ADC_CALIB_OFFSET, ADC_SINGLE_ENDED)

  • Used

    HAL_ADCEx_Calibration_Start(adc2, ADC_CALIB_OFFSET_LINEARITY, ADC_SINGLE_ENDED)

    HAL_ADCEx_LinearCalibration_GetValue(adc2, LinearCalib_Buffer);

    HAL_ADCEx_LinearCalibration_SetValue(adc2, LinearCalib_Buffer);

All the above combinations did not affect the 'sticking' anomaly.

Another note: The linearity calibration factor is only recalculated/loaded if we use the parameter ADC_CALIB_OFFSET_LINEARITY instead of ADC_CALIB_OFFSET in the function HAL_ADCEx_Calibration_Start

MasterT
Lead II
July 31, 2025

Would you mind to post LinearCalib_Buffer values, as it was done in another thread I linked?

Simply 

HAL_ADCEx_Calibration_Start(&adc2, ADC_CALIB_OFFSET_LINEARITY, ADC_SINGLE_ENDED)

HAL_ADCEx_LinearCalibration_GetValue(&adc2, LinearCalib_Buffer);

and print results.

Visitor II
August 6, 2025

There are also other lessor symmetrical anomalies. Several reasons come to mind:

1. The ADC internal opamp gain resisters may be inaccurate. Can you try a different MCU?

     Edit: or different ADC?

2. The time between conversions may not be uniform. Is the timer and ADC conversion at the highest priority?

3. The signal source may not be linear with time. 

SahielAuthorBest answer
Associate
September 17, 2025

This issue was resolved when the F_adc which was 35Mhz was reduced to 6.25Mhz

waclawek.jan
Super User
September 18, 2025

> This issue was resolved when the F_adc which was 35Mhz was reduced to 10Mhz

According to STM32H7B3 datasheet, the maximum ADC clock frequency is 50MHz, but ADC_CR.BOOST has to be set accordingly.

@Sahiel , how was BOOST set with Fadc=35MHz, when the problem was observed - was it 0b11?

JW