Step in ADC data

[kai239955]

Posted on May 19, 2010 at 15:54

Step in ADC data

#stm32-adc

[swhite2]

Posted on May 17, 2011 at 13:51

Are you using DMA to transfer A/D results or are you polling the ADC_DR register (directly or via the library)? If you're converting more than one channel you need to use DMA.

''Since converted regular channels value are stored in a unique data register, it is necessary to use DMA for conversion of more than one regular channel. This avoids the loss of data already stored in the ADC_DR register.'' If you're not using DMA with multiple channels then the A/D result register (ADC_DR) might not reflect the channel you think it does. That would explain the large differences you're seeing.

[kai239955]

Posted on May 17, 2011 at 13:51

Thanks Stuart for you feedback.

I look in the code and I see that we are using the command ADC_GetConversionValue wich return the latest conversion data from the ADC. This is a function from ST. Is this not the way to get the value from the ADC?

[swhite2]

Posted on May 17, 2011 at 13:51

That is only reliable if you're converting a single channel. Converting more than one channel requires that you use DMA (into RAM).

BTW there's an example showing how to use DMA with the A/D in the ST Standard Peripheral Library. Look in the Project\STM32F10x_StdPeriph_Examples\ADC\ADC1_DMA sub-folder.

[StefanoBettega1]

Posted on May 17, 2011 at 13:51

Hi, we are experiencing the same issue with two different µC (an STM32F103VD and a STM32F103ZE), while a simpler STM32F103RB seems not to be affected by this problem. Even converting a single channel sometimes we have a spike in conversion.

We analyzed the problem and it seems to be related to noise injected from the GPIO lines: we connected the analog input to ground, and converted the channel, with reading that seemed to be right (only affected by very low noise, 3LSB wide); when converting the channel while our main program was moving GPIO lines (if I well remember on STM32F103ZE problem seems to be tightly coupled to GPIOG and GPIOE lines), suddenly we experienced sporadic high value readings (raw values were around 72 levels). We found this problem also affecting the STM32F103Z evaluation board.

[StefanoBettega1]

Posted on May 17, 2011 at 13:51

I don't think the problem is related to data transfer, as it occurs also converting a single channel. I think the noise is due to GPIO ports glitches injected into analog converter inside the µC (don't know if on its power supply or via sampled inputs). Maybe this is related only to high density devices, as on STM32F103RB does not occurs with an similar test code.

[aeolia_amha]

Posted on May 17, 2011 at 13:51

When converting simulataneous ADC channels, I suggest using an array like ADCConvertedValueTab[];

[StefanoBettega1]

Posted on May 17, 2011 at 13:51

Actually our test collects data within a circular buffer. If the collected value is over a certain threshold, it will increment a counter of ''mistaken values''. We can view vector data and counters using JTAG device.

As with input shorted to ground you should normally read only few A/D level (i.e. 7), our threshold was fixed to 30 and sometimes we read out values around 70 A/D levels, that is impossible to have. If we stop toggling GPIOs lines from main program, wrong readings disappear. I'm wondering if this is a common problem on STM32F103V and STM32F103Z version, as on STM32F103R seems not to occur.

[aeolia_amha]

Posted on May 17, 2011 at 13:51

I am unsure since I only use STM32F103RB. How did you read the ADC converted value, did you use printf and outputted it in hyperterminal? or did you output the input voltage in another GPIO port and measured it in an oscilloscope? How did you confirm that there is a spike?

[juergen239955_st]

Posted on May 17, 2011 at 13:51

We also had problems with steps in ADC. We are using stm32F105VC. After several tests we found out, that the clock for adc must be configured as following.

RCC_ADCCLKConfig(RCC_PCLK2_Div4); with   ''RCC_PCLK2_Div2'' we have steps at 512,1024,2048