ADC pin to GND, doesn't show full zero

[oldschoolmountainbike]

Hello! Is it normal ,that when I connect ADC pin to GND IDE doesn't show full zero?

ADC Value: 272, Voltage: 0.01 V,

Raspberry Pi Pico with RP2040
MicroPython v1.23.0
IDE:Thonny

import machine
import time

adc = machine.ADC(26)   
vref = 3.3          
conversion_factor = vref / 65535  

while True:
    raw_value = adc.read_u16()  
    voltage = raw_value * conversion_factor   
    print(f"ADC Value: {raw_value}, Voltage: {voltage:.3f} V")
    time.sleep(0.1)

[robert-hh]

ADCs in general purpose MCUs like the RP2340 usually lack precision. Especially at the end of the range they show greater non-linearity, and the effective resolution is smaller than the claimed bit width. The ADC of the RP2040 has more issues. See e.g. https://forums.raspberrypi.com/viewtopic.php?f=144&t=299904 and https://forums.raspberrypi.com/viewtopic.php?f=144&t=299904&p=1833277#p1833277
If you need a precise ADC, use external devices designed for dealing with analog values, like for instance the ADS1115 of analog devices.

[robert-hh]

If I repeat that test here with a RP2040, ADC(1) at GP27 connected to AGND just next to it. read_u16() returns values between 272 and 304. A RP2350 returns values between 0 and 64

[mendenm]

Ouch! That's a way-bigger zero offset than I would have expected.

Is the input pad correctly configured for analog-only service (no bus drivers hanging on it)
(As per the note in section 4.9 of the RP2040 data sheet)? This means having set the IE (input enable) bit low, and OD (output disable) high in the pad control register for the A/D pin in use? (Is this being overlooked somewhere in the micropython A/D config?)

I will fire up my pico shortly and check thew pad register after setting up an A/D in micropython, to see if it is right.

Does it stay this way if you make multiple consecutive measurements (with the ADC in timed mode) so it doesn't suffer charge injection while being reconfigured?

I know the ADC on the RP2040 is funny, but this seems way out of the expected range.

[robert-hh]

When the ADC argument is a Pin object or a number > channel# (e.g.26), the pin is initialized as a ADC pin, with IE set to low and Output disabled. If just channel number is used, the pin is not separately configured. That is left to the user. See https://docs.micropython.org/en/latest/rp2/quickref.html#adc-analog-to-digital-conversion.
But the reading for shortened input is the same, no matter how the ADC object is instantiated.

[mendenm]

OK, this has to be something on the Pico board, unless the graphs in 4.9.4 of the rp2040 manual are just plain wrong (they show typical 1 LSB error, even near zero, for the naked chip). I pulled out some of my old code which directly drives the ADC, and get the same sort of results you are getting. I expected much better. Note that my multiple-acquisition code assures that after the first measurement, there is no charge-injection error on the ADC.

Code attached:

import machine
import time
import uctypes

adc_idx = 2
adc_pin_idx = adc_idx + 26

adc = machine.ADC(adc_pin_idx)   

#set regulator in PWM mode for better stability,  per section 4.3 of Pico manual
SMPS = machine.Pin(23, machine.Pin.OUT)
SMPS.value(1)

pad_base = 0x4001c000

pad_reg = pad_base + 4 * (adc_pin_idx + 1) #4 bytes / pin + skip VOLTAGE_SELECT register

if 1:
    machine.mem8[pad_reg] = 1 << 7 #put this pin in analog-in mode with OD = 1, IE = 0

print(f"{machine.mem8[pad_reg]:02x}")

vref = 3.3          
conversion_factor = vref / 65535  

for i in range(10):
    raw_value = adc.read_u16()  
    voltage = raw_value * conversion_factor   
    print(f"ADC Value: {raw_value}, Voltage: {voltage:.3f} V")
    time.sleep(0.1)

def setup_timed_adc(idx: int, freq_hz: int) -> (int, int, int):
    import pico_devices
    pico_devices.PAD_PINS[idx + 26].PAD_REG = 1 << 7 #put pin in analog mode
    adc_device = pico_devices.ADC_DEVICE
    adc_device.CS_REG = 0 #clear all to start
    adc_device.CS.ERR_STICKY = 1 #clear sticky error bit
    adc_device.FCS_REG = 0 #clear all to start
    adc_device.DIV_REG = (48_000_000 // freq_hz - 1) << 8 #fractional part is low 8 bits, set to zero, do before enable per instructions
    adc_device.CS.AINSEL = idx #select the channel to read
    adc_device.FCS.EN = 1 #use fifo
    #adc_device.FCS.DREQ_EN = 1 #DMA DREQ generated
    #adc_device.FCS.THRESH = 1 #per instructions for DMA

    fcs_reg = int(uctypes.addressof(adc_device.FCS))
    cs_reg = int(uctypes.addressof(adc_device.CS))
    
    while adc_device.FCS.LEVEL != 0: #LEVEL field !=0 -> data available in FIFO
        x = adc_device.FIFO_REG #dump data from before we started

    adc_device.CS.EN = 1 #turn on power, but don't start running until START_MANY is set

    return adc_device, fcs_reg, cs_reg

def grab_adc_paced(adc_device, fcs_reg, cs_reg, npts):

    results = []
    
    machine.mem32[cs_reg] |= 1 << 3 #and kick ADC into action with START_MANY
    
    di = 0
    
    while di < npts:
        
        while not machine.mem32[fcs_reg] & 0xf0000: #LEVEL field !=0 -> data available in FIFO
            pass
        v = machine.mem32[fcs_reg+4]
        results.append(v*16) #convert to 65536 full scale
        di += 1
    return results

res = grab_adc_paced(*setup_timed_adc(2, 10000), 10)
print(res)

and results

>>> %Run -c $EDITOR_CONTENT

MPY: soft reboot
80
ADC Value: 160, Voltage: 0.008 V
ADC Value: 144, Voltage: 0.007 V
ADC Value: 144, Voltage: 0.007 V
ADC Value: 144, Voltage: 0.007 V
ADC Value: 144, Voltage: 0.007 V
ADC Value: 144, Voltage: 0.007 V
ADC Value: 144, Voltage: 0.007 V
ADC Value: 144, Voltage: 0.007 V
ADC Value: 128, Voltage: 0.006 V
ADC Value: 144, Voltage: 0.007 V
[128, 128, 128, 144, 128, 144, 128, 128, 128, 144]
>>> 

[mendenm]

I think I see the problem on the Pico board. The lower-left corner of the diagram on page 24 says the following: "ADC GPIO pins have diode to VDDIO...". This is probably leakage current through those diodes. It seems like a lot of leakage, but I suspect this is the issue.

I also notice that the pico AGND pin isn't anything special...it's just a ground physically near the ADC pins. The rp2040 itself doesn't actually have a separate AGND pin that is directly connected to its SAR comparator, so behavior does depend on a nice, quite ground bus.

[mendenm]

@oldschoolmountainbike Just to beat this topic to death a bit, it is worth noting that the rp2040 manual very correctly points out that the best way to get a/d results is to use two channels. You permanently ground one channel, and use the other for your measurements, and use the difference as the returned value. This corrects for the input offset voltage drift in the sample-and-hold amplifier. Depending on the design of the amplifier, this can be quite temperature sensitive, and therefore it can shift as your CPU utilization shifts, or as the ambient temperature shifts, both of which will change the die temperature. Doing this can result in nearly order-of-magnitude improvements in the behavior for voltage near the bottom of the a/d range. As you initially observed, you were getting something like 7 mV offset. By using the nulling against a second input, this can be close to a single count. Note that most of the offset comes from the input amplifier, not the multiplexer, so shifting from one input to the next doesn't change that offset.
The other issue, which I alluded to in a previous post here, is the problem of charge injection. If you are sampling slowly, there is plenty of time for the s/h capacitor to charge. As you approach the 500 kHz limit, the capacitor may not fully charge/discharge to the currently selected multiplexer channel voltage, and there will be coupling between the channels, so a high voltage channel being read just before a low voltage channel may result in serious errors on the low voltage channel.

[oldschoolmountainbike]

@mendenm Thank you for participating in the discussion and sharing useful information! This information is very valuable to me.