cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G071RB 12BIT ADC provides a non-zero output even with a zero volt tension input

MCarc.1
Associate

I was doing some tests on a NUCLEO-G071RB and I found out that the ADC has always some sort of offset in its digital output. I measure the tension on the MCU's pin and it's zero volts, but when I read the ADC the output is not zero. It can be 26-27 digits, 50-51 digits or 75-76 digits depending on the board that I'm testing. This happens also with an "empty" project where the ADC read is the only action that I'm doing, and I'm sure that the tension on the physical pin is zero Volts. Why I do get this behaviour? Is it normal?

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

The ADC output should be very close to 0 when the input is grounded, typically within a few counts if not exactly 0.

Do you calibrate the ADC on startup?

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

5 REPLIES 5
TDK
Guru

The ADC output should be very close to 0 when the input is grounded, typically within a few counts if not exactly 0.

Do you calibrate the ADC on startup?

If you feel a post has answered your question, please click "Accept as Solution".

Yes, now I tried to calibrate the ADC on startup and now it works as expected, thank you!

RBein.1
Associate III

This thread relates to an issue I'm currently facing. I'm using the STM32G071C8U7 microcontroller, and despite calibrating the ADC and obtaining mostly accurate measurements, there is an inherent noise problem. When shorting one ADC channel to ground, I can't achieve a 0 count. Instead, the ADC measurement varies by 3 counts, occasionally spiking even higher. This issue persists across multiple boards (non-dev boards), causing concern as the signal is vital for closed-loop control.

In the initial implementation, the ADC runs at a 12 MHz clock frequency, triggered every 15 us. I sample 5 channels, each for 3.5 ADC, totaling 6 PCLK. In this MCU, the VREF+ pin is external and I have it connected directly to the VDD/VDDA pin. I recall three major noise-contributing factors in noisy ADC measurements: power supply, reference voltage, and external measurement circuitry. To address the external circuitry issue, I used a free pin with no external connections, shorting it directly to ground. However, the measurements never really reads 0, instead it oscillates by 3 counts.

Finally, I conducted another test to assess potential issues with the noisy VREF+ by disconnecting it from VDD/VDDA. I used an internal voltage reference of 2.048 (VREFBUF) with a 100 nF external 0603 X7R cap. Unfortunately, this did not resolve the issue, as the same random noise persisted, fluctuating by 3 LSB. And yes I did implement the wait function which ensures that VREFBUF is enabled correctly. 🙂

Now, I'm considering whether the LDO voltage of 3.3V, powering all analog/digital circuitry, might be the problem. However, the LP2985-33DBVRM3 LDO which is from TI has excellent characteristics and isn't working at full capacity. Options to address this noise-related problem seem limited now. I suspect that the merging of analog VDDA/VSSA and digital VDD/VSS power supply pins in the STM32G0-based MCUs could be contributing to this issue. In contrast, using STM32F051K4U6 MCUs previously didn't result in such significant random noise across all analog pins.

 I wonder if there is anything that could be done to suppress this noise further (apart from filtering it in software) or should I look for a different MCU that has dedicated analog power supply pins instead? Another solution perhaps would be to go with STM32G4 series, but that is relatively more expensive MCU. Please reach out to me regarding this mater ST engineers or other folks that have experience with this problem. All advices are appreciated in advance.

@RBein.1,

Please start a new thread, copying this post to it.

JW

PS. Before you'd jump on the 'G4, read its ADC-related errata and it's specific ADC appnote.

Thanks, I already created another thread as you suggested.