Why my ADC value alternates when signal is steady?

[Henrik Sandaker Palm]

Posted on December 29, 2016 at 15:53

Hi,

I'm quite new to STM32 and Cube HAL. Hardware is custom, mcu is STM32F042G6Ux, created initial code with Cube MX. IDE is 

SW4STM32.

The issue is that the ADC value is alternating somewhat between two values (roughly 300-something mostly and sometimes 1700-something). I see it while debugging, I do one iteration of the main while-loop and watch the ADC value

adc_val

 returned from HAL_ADC_GetValue function. The voltage is around 450mV. The reading of the internal temperature via ADC is stable and fine.

Here is the code (how to embed code properly?): 

http://pastebin.com/rvLLcXsk

 

[Lynn Linse]

Posted on December 29, 2016 at 18:10

What are you reading? Make sure the source isn't changing due to some physical property.

A simple example, if it is a 'light' sensor, the flicker in florescent office lights causes the signal to fluctuate widely, as sometimes you're measuring the space when the bulb is 'off' (but human eye's don't notice) and sometimes it's on.

[Seb]

Posted on December 29, 2016 at 18:25

Best would be to start a code from one cube example (for nucleo or discovery board).

Otherwise, if you'd like to test the ADC, don't connect anything to the pin, make sure it is configured for analog function.

Read ADC value. Then manually (debugger breakpoint) turn on the pull-up resistor on the pin, and run a while the code to read the new ADC value, rinse and repeat with a pull-down resistor. If the values are not making sense, reduce the ADC to 8 bit mode, maximize the conversion time to make sure the ADC reference clock is within valid range (it depends on the core frequency).

Good luck!

[Henrik Sandaker Palm]

Posted on December 30, 2016 at 22:21

Hi Lynn and Seb,

Thanks for answering!

I'm measuring the analog output-signal from a RF power detector, specifically the ADL5903. It does not have any input, but the output is nevertheless 480mV, so that's what I'm trying to read. 

At first I thought the higher values I read was the jitter on the measured signal, as seen below:

But then I decoupled the signal with a capacitor and it looks like this now:

So I don't believe it's a physical thing, the signal is clean and I've traced it over time. After the decoupling the read signal i far more stable though, in both ends (now it's almost exactly 390 or 1650 each time, before it deviated more).

I made a crucial new discovery. The raw value of the temperature is always the same as adc_val when it's at its high level (1650). So it's obvious to me that somehow I managed to sometime share the adc value between these two channels. But how...

[T J]

Posted on December 31, 2016 at 00:38

In the old days (20 years ago), we had to read a AD channel twice , the second reading was always good. This may just be your problem.

Also, these days the ST parts suck a little as they read.

So you need a 0.1uF at least to the input pin. (or a 4.7uF if you can on a slowly changing input) not likely to be your problem.

Also,

if you have pullups turned on, this can change the reference rail slightly and your values will change slightly when the IO pin is high or low. but I don't think this is your problem.

[Henrik Sandaker Palm]

Posted on December 31, 2016 at 01:27

Hi marsh.nick.

Thanks for replying. I have decoupled the adc pin. 

I set up the adc in cubemx but I will check again if I somehow put pullups on. 

Just discovered that the adc reading from the temperature channel varies between the same two values. It's quite clear that the ~1700 value is from the actual temp channel though since it's so near the internal calibration value for 30 degrees. 

[T J]

Posted on December 31, 2016 at 03:18

did you try to read the ADC a few times in a row to compare the values, ?

any pullup function on any pin will have some effect, best to pullup lightly outside.

but your swing is huge, you have a ADC result pipelining problem,

hence I suggest to read it a couple of times.

[Seb]

Posted on December 31, 2016 at 06:39

Probably the ADC programming needs to be revisited. Either it's a GPIO handling, a MSB/LSB management, or the ADC clock and timings are incorrect and out of range, or the ADC supply pins (if present) should be checked. The ADC is a SAR (successive approximation) which looks like a binary search algo: if the ADC timings are wrong, it's normal to miss a bit from MSB to LSB. Again, starting from a working example would reduce debug time.

Good luck!

[Andrei Chichak]

Posted on December 31, 2016 at 08:09

What is the value being returned by HAL_ADC_PollForConversion?

If one of the returned values is about right and the other is wrong, it sounds like the second conversion isn't finished and you are unloading a bogus conversion.

A 

[Henrik Sandaker Palm]

Posted on December 31, 2016 at 12:43

The return values are always 0.