cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 ADC DMA low raw/Voltage readings

KoSt
Associate III

Hello,
I am experiencing the following problem. When I setup an ADC with DMA for 5 channels, occasionally I get lower readings than the expected ones. It also happens in some of our hardware of our production, but others perform ok. We have inspected the components and everything seems identical. We have measured the reference voltage and all the expected voltages on ADC input pins (some are fixed and known) and all looking good too. On the other hand, when I sample only one ADC channel in polling mode, I do not get this problem, the voltages read as expected.
Here is the ADC configuration with DMA (source code attached too):

KoSt_0-1711711015173.pngKoSt_1-1711711038152.png

KoSt_2-1711711052740.png

KoSt_3-1711711167318.png

 

24 REPLIES 24
KoSt
Associate III

 

 

 

	Set_String_Tx_Buffer("factory Vrefint== ");
	Message_16_Bit_Number(*VREFINT_CAL_ADDR);
	Set_String_Tx_Buffer(NEWLINE);
	Set_String_Tx_Buffer("calibration factor== ");
	Message_16_Bit_Number(HAL_ADCEx_Calibration_GetValue(&hadc1));
	Set_String_Tx_Buffer(NEWLINE);
	Set_String_Tx_Buffer("ADCrefINT== ");
	Message_16_Bit_Number(ADCreadings[VREFINT]);
	Set_String_Tx_Buffer(NEWLINE);

 


The output of the code above is:

factory Vrefint== 1668
calibration factor== 79
ADCrefINT== 379

I remind you that this issue with the gain appears on multiple channel sampling via DMA, but not on single channel sampling via polling. I was thinking: is this maybe another HAL library issue similar as what happened with the calibration function?

> ADCrefINT== 379

Assuming that was taken as 10-bit measurement, after calibration (i.e. the ADC is already "true"). That then can be used to calculate the real VREF+ voltage:

3.0V * (1668 / 4096) / (379 / 1024) = 3.301V

JW

KoSt
Associate III

This solution seems that is fixing the original problem (more testing is needed to verify further all readings), but while we testing, we get unresponsive devices after the introduction of the ST ADC calibration, hence no device has managed to complete the full cycle of testing.

> we get unresponsive devices after the introduction of the ST ADC calibration

What does this mean? Did you positively locate the problem to be in the calibration? Maybe this? Or is the problem elsewhere?

JW

KoSt
Associate III

The issue was that the STM32 Cube MX has overwritten the configuration of the wake up pin, hence the microcontroller was actually running in sleep mode, but we could not wake it up.

We can consider this issue as resolved.

The offset calibration has been achieved by the ST HAL function as long as you modify the drivers adding a delay after an ADC switching ON or OFF.

The gain calibration (the biggest issue in my case) it has been resolved by using the Vrefin channel to calibrate all ADC readings.

Thank you for your support.