Value optimized out when reading from ADC.

[MReyn]

Hello everyone,

i'm encountering a strange issue, I'm trying to read from the ADC on a STM32f429zi.

When my pin is grounded the value of the ADC is not 0 but around 1000. When i try to debug the value it doesn't give me any result but says: <optimized out>. This is the code i'm using:

	  uint32_t value = 0;
	  HAL_ADC_Start(&hadc1);
	  HAL_ADC_PollForConversion(&hadc1, 100);
	  value = HAL_ADC_GetValue(&hadc1);
	  HAL_ADC_Stop(&hadc1);

I'm using system workbench for stm32 with a ST-link using SWD. I hope somebody can help me solve this issue. Thank you all!

[TDK]

1. Change your compiler setting to "Debug" so it doesn't optimize out variables.
2. Is that pin initialized correctly? Did you set up the correct channel?

[MReyn]

Thank you for your reply,

i was able to view the exact value of the ADC, when i apply 3.3V the readout is correct. But when i apply 0V to the ADC input pin, the result shows 1023 and this should be zero. What can be the cause of the ADC reference drift? I again confirmed my input voltages and those were ok. When i apply around 0.4V to the input pin the ADC already goes to 4095. Attached you can find my ADC settings

[TDK]

It is unlikely that you'll get a reading of 1023 if the pin is really at GND. The negative voltage reference is GND, and that doesn't drift relative to itself. I would recheck your assumptions.
What sample time are you using? Change it to the highest and try again.
Tips for general ADC accuracy can be found in AN2834.

[etheory]

To avoid value being optimized out, it should be set as volatile.

i.e.

volatile uint32_t value = 0u;

[MReyn]

I checked this with my scope and multimeter, the input pin is 100% sure at ground. Even when i apply around 0.4v at the input pin the result already goes up to 4095. I guess this has nothing to do with accuracy but there is a major problem here? I tried different sample rates and resolutions. They all have the same drift. I checked my Vdda and Vssa pins and the make good contact and are at the correct voltage. I have no clue what to look for at this point?

[TDK]

Yeah, sounds like a hardware problem. It is possible to blow out the circuitry if you apply a voltage outside the range. The rest of the chip may still work fine but the ADC parts will not.

You could try reading the VREFINT channel. If that comes back as 4095 then definitely there's an issue. If that comes back valid then maybe there's something else that is amiss.

Is the ADC clock in a valid range?

[MReyn]

Where can i find the VREFINT channel? And what value should it be? I've hand soldered this chip and it took my quite some effort and heat to get it on, i won't say i've abused the chip but i got the same results with a previous chip(but broke that one for another reason). I'm not an ADC expert so i don't now about the clock? I've been reading the application note and i guess the impedance for the ADC input might be too high. I'm using a voltage divider ( LDR and 10k resitor the LDR goes up to 60k when dark). I've tested this with a nucleo without any problems, but now this is on my own pcb. So to resume it looks like my ADC only has a range of around 0.4v and has a 25% zero offset. Would it make a difference if a choose another ADC? I hope you can give me some test points and would like to thank you for your support!

[TDK]

VREFINT is typically 1.21V (check your datasheet) and typically available on channel 17 (check reference manual).

A high impedance may explain what you're seeing, but if that's the case then the pin is not "grounded" and "100% sure at ground" as stated in your OP. Perhaps you can share the relevant portion of your schematic.

All ADCs have the same characteristics, but if something is wrong with ADC1, then using another one might give different results.

The ADC clock is configured in CubeMX or in the CCR->ADCPRE register field.

[Imen GH]

Hello,

I have reproduced the case on my side and I don’t have any problem (when using ADC1_CH3 on PA3).

when I apply 0V to the ADC input pin, the obtained result is already 0, as shown in Figure (when using IAR).

In addition, I used a potentiometer in input and it can be confirmed that the obtained values vary between 0 and 4095.

Please find attached my file main.c .

Best regards,