ADC output ranging about 2000 up to 4095

[APTT]

I'm running an STM32L452RCTX uC, and I'm trying to implement a 2.5Vref+ ADC.

Things weren't looking quite right on the pins I intend to implement, so for now I'm driving a floating TP with a power supply so I can directly test input vs output.

When driving the pin to ground, the output is around 2000 (I've seen it in the 198X through 200X range).

When increasing the voltage, I reach the full 4095 at 2.35V, which I feel is reasonably close to my measured 2.482 reference for my application.

I've scoured everywhere I can think of, and I can't seem to find any information on why this might happen.  The behavior is almost as if the Vref- is somewhere near -2.5V, but I have that pin (confirmed through measurement) tied to ground.

As for circuitry, I have 3.3V running through a 470 ohm resistor to the top of a 2.5V zener (LM4040), across two caps to ground (2.2uF and 0.1uF), and through a series 0 ohm resistor into the Vref+ pin.  The Vref- pin is soldered directly to the ground plane.  The test point I am driving is about 3mm from the pin of the uC.

And the programming, using the HAL drivers:

//Additional initializations beyond HAL implementation
	HAL_ADC_Stop(&hadc1);
  	HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED);

//Battery checker, in main loop
	if(check_adc && ((hadc1.State & HAL_ADC_STATE_READY) == HAL_ADC_STATE_READY))
		{
		//Configure ADC for conversion
		adc_channel = TP_ADC;
		sConfig.Channel = adc_channel;
		sConfig.Rank = 1;
		if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
			{
			Error_Handler();
			}
		if (HAL_ADC_Start(&hadc1) != HAL_OK)
			{
			Error_Handler();
			}
		if (HAL_ADC_PollForConversion(&hadc1, 100) != HAL_OK)
			{
			Error_Handler();
			}
		if (HAL_ADC_Stop(&hadc1) != HAL_OK)
			{
			Error_Handler();
			}
		if (HAL_ADC_Start(&hadc1) != HAL_OK)
			{
			Error_Handler();
			}
		if (HAL_ADC_PollForConversion(&hadc1, 100) != HAL_OK)
			{
			Error_Handler();
			}
		uint16_t temmp = hadc1.Instance->DR;
		HAL_ADC_Stop(&hadc1);
		check_adc = NO;
		adc_check_timer = ADC_CHECK_TIME;
		}

Registers while device is paused, currently a floating pin:

And measured results of the DR register:
Pin grounded: 0x7C0

Pin floating: 0x8E2

Pin 3.324V: 0xFBF

[TDK]

Does calibration complete successfully? Does HAL_ADCEx_Calibration_Start return HAL_OK?

I'd try removing the LM4040 (which effectively shorts VDD to VDDA via a 480 Ohm) and seeing if you get the same behavior. If so, probably a hardware issue.

Does it happen on multiple chips?

Can you try that code on known good hardware such as a nucleo board?

[APTT]

I modified the code to check for any status != HAL_OK on the calibration, and a nop for a breakpoint, and the code operates right past it without issue.

I tried the same code on an STM32L4P5CETX with identical Vref setup, floating test point, and results.

I do have an STM32L4R9 Discovery kit I'll try it on next.  If it works fine on there, I'll look into testing my board without the LM4040.

I'm hesitant to suspect a defective LM4040 (I assume that's what you're getting at), as I've measured that voltage with both DMM and O-scope, it's a clean 2.482V even during conversions.

[APTT]

Annnd, it appears as if all my dev boards are either obsolete and not showing up on the computer, or fried.

My nucleo board is CC at 1.6V no matter what I power it with (following datasheet).

[TDK]

I don't suspect a defective LM4040 either, but the problem has to lie somewhere. Eliminating LM4040 from the equation certainly simplifies things.

If, after removing LM4040, it starts working, issue was something to do with LM4040, probably.

If it still isn't working, issue is likely your hardware. Let's list the possibilities in no particular order:

• Chip is damaged/defective.
• Code is bad.
• Pin isn't hooked up how you think it is.
• You are misinterpreting the results in some manner.

Could be missing one but I think that covers it.

You don't mention what pin is having this issue. Some pins are hooked up internally to things or otherwise require some setup beyond the norm.

Testing it on known good hardware would absolve the code of bugs, mostly, and suggest the issue is related to your hardware. Bummer your boards aren't working. This would also eliminate pin-related issues like the previous point.

[waclawek.jan]

Taking ADC reading of the internal VREFINT and/or temperature sensor returns what value?

Did you measure voltage directly on the pin you use as ADC input? And on VREF+ pin? You don't try to use the internal VREFBUF, do you?

VDDA is connected how? Is this package with separate VDDA/VREF+? VSSA is connected to VSS?

If you omit the LM4040 and connect VREF+ directly to VDD/VDDA, what is ADC result?

JW

[APTT]

ADC reading of internal VREFINT returns 0x5a +/- 2

I measured voltages directly on the pins, as well as visually verifying good solder connections (I have good magnification available).  I do not try to use the internal VREFBUF.

My VDDA pin is the same pin as VREF+, and is soldered directly to the ground plane.  Not the best idea with regards to noise, but I can deal with that.

I have yet to eliminate the LM4040, I'm about finished trying to see if any of my dev boards still work.

[APTT]

I am having this issue on pins PC0, PC1, AND PA2, and my ioc file leads me to believe there are no conflicts as far as my setup (I'm aware hal can often do its own thing...).

Aside from visually verifying the solder connections are excellent on both of my boards, the fact both boards are resulting identically makes me believe there is something in the software setup.

If it weren't for non-competes and the like, I'd be able to post my actual code here, but what I posted above is truly everything I've implemented for ADC.  Anything left is code fully generated by HAL on my STM32L452RCTx.

[APTT]

HCLK is set for 80MHz, ADC settings are below:

[APTT]

Removing the LM4040 from the board yielded similar results.

The ADC pin reads around 0x83A when floating, 0x7C0 when grounded, and 0xFB0 when 3.3V is applied.

Calibration came out fine.  Floating at 0x800s makes me think maybe an underflow resulting in negative values, but then why would ground not also show a sign mark?  But then, 12 bit numbers would sign on bit 15 or 31, right?