PR2: How to use ADC channel 3/GPIO pin 29 to measure VSYS on Pico W board

[devegied]

firmware: rp2-pico-w-20221220-unstable-v1.19.1-782-g699477d12.uf2
board: rp2-pico-w
version information: MicroPython v1.19.1-782-g699477d12 on 2022-12-20; Raspberry Pi Pico W with RP2040

MicroPython program

import machine
import sys

print("sys.implementation:{}".format(sys.implementation))
print("sys.version:{}".format(sys.version))
pin = machine.ADC(29)
adc_reading  = pin.read_u16()
adc_voltage  = (adc_reading * 3.3) / 65535
vsys_voltage = adc_voltage * 3
print("""ADC reading:{}
ADC voltage:{}
VSYS voltage:{}""".format(adc_reading, adc_voltage, vsys_voltage))

on Raspberry Pi Pico W outputs

sys.implementation:(name='micropython', version=(1, 19, 1), _machine='Raspberry Pi Pico W with RP2040', _mpy=4358)
sys.version:3.4.0; MicroPython v1.19.1-782-g699477d12 on 2022-12-20
ADC reading:608
ADC voltage:0.0306157
VSYS voltage:0.09184711

on Raspberry Pi Pico it outputs

sys.implementation:(name='micropython', version=(1, 19, 1), _machine='Raspberry Pi Pico with RP2040', _mpy=4358)
sys.version:3.4.0; MicroPython v1.19.1-782-g699477d12 on 2022-12-20
ADC reading:33032
ADC voltage:1.663319
VSYS voltage:4.989957

equivalent CircuitPython program

import analogio
import sys
from board import VOLTAGE_MONITOR

print("sys.implementation:{}".format(sys.implementation))
print("sys.version:{}".format(sys.version))
pin = analogio.AnalogIn(VOLTAGE_MONITOR)
adc_reading  = pin.value
adc_voltage  = (adc_reading * pin.reference_voltage) / 65535
vsys_voltage = adc_voltage * 3
print("""ADC reading:{}
ADC voltage:{}
VSYS voltage:{}""".format(adc_reading, adc_voltage, vsys_voltage))
pin.deinit()

on Raspberry Pi Pico W (same board) it produces output

sys.implementation:(name='circuitpython', version=(8, 0, 0), mpy=517)
sys.version:3.4.0
ADC reading:33192
ADC voltage:1.67137
VSYS voltage:5.01412

I know that on Pico-W this pin is shared with WiFi module. But I can not get correct output from Pico-W event after fresh .uf2 firmware upload with 0 WiFi module usage.
CircuitPython made special case for this pin. And it works perfectly. CircuitPython indicates active REPL with onboard LED. On Pico-W that LED is controlled by WiFi module, but event with active LED I can get ADC values from REPL prompt.
Maybe this solution can be ported to MicroPhyton?
Also it can be regression with new Pico SDK or latest changes in rp2 MicroPython port. In older forum posts I can find examples that VSYS measurement was working even while using WiFi module. But I don't know where can I get older MicroPython .uf2 files

Some related discussions:
https://forums.raspberrypi.com/viewtopic.php?t=339994
https://forums.raspberrypi.com/viewtopic.php?t=301152

[th3w]

Have you tried the provided solution here? Looking through this thread there seems to be problems restarting the wifi modul again, after changing GPIO29 and 25 to be able to read VSYS with ADC 3
Can't test it myself at the moment.

https://forums.raspberrypi.com/viewtopic.php?p=2062543&hilit=ADC+29#p2062568

[devegied]

Thank you, that recommendation worked. Test code:

import machine
import sys

print("sys.implementation:{}".format(sys.implementation))
print("sys.version:{}".format(sys.version))
wl_cs = machine.Pin(25) # WiFi chip SDIO_DATA3 / gate on FET between VSYS divider (FET drain) and GPIO29 (FET source)
print("Initial WL_CS (GPIO25) state:{}".format(wl_cs))
wl_cs.init(mode=machine.Pin.OUT, value=1)
pin = machine.ADC(29)
adc_reading  = pin.read_u16()
adc_voltage  = (adc_reading * 3.3) / 65535
vsys_voltage = adc_voltage * 3
print("""ADC reading:{}
ADC voltage:{}
VSYS voltage:{}""".format(adc_reading, adc_voltage, vsys_voltage))
wl_cs.init(mode=machine.Pin.ALT, pull=machine.Pin.PULL_DOWN, alt=31)#try to restore initial WL_CS state

and output

sys.implementation:(name='micropython', version=(1, 19, 1), _machine='Raspberry Pi Pico W with RP2040', _mpy=4358)
sys.version:3.4.0; MicroPython v1.19.1-782-g699477d12 on 2022-12-20
Initial WL_CS (GPIO25) state:Pin(25, mode=ALT, pull=PULL_DOWN, alt=31)
ADC reading:32968
ADC voltage:1.660096
VSYS voltage:4.980288

It means that MicroPython initializes GPIO used for WiFi module even if module is never used.
I don't know what solution is the best in this case:

• only document such behavior in RP2 port section
• document such behavior and do not initialize GPIO's connected to WiFi module while module is not used
• add special handling for these pins in MicroPython code (that question was raised in Pico W - Issue with LED & Wifi Module control #10248)

[th3w]

There is a call to initialize the cyw43 driver directly in /ports/rp2/main.c when the rp2 firmware is build with the MICROPY_PY_NETWORK_CYW43 flag.
The call cyw43_init() leads to https://github.com/georgerobotics/cyw43-driver/blob/main/src/cyw43_ctrl.c where the pins are configured.
A network.WLAN().deinit() will call the cyw43_deinit() function there, but it this seems that cyw43_deinit() calls cyw43_init() again at the end.

 // Power off the WLAN chip and make sure all state is reset.
    cyw43_ll_deinit(&self->cyw43_ll);
    cyw43_init(self);

This means, to use a WL_GPIO pin in a alternative mode, it must always be reconfigured manually

[devegied]

It seems that I have not read Pico W datasheet carefully enough. There is a section about pins used for WiFi module and explanations about need to put GPIO25 high when using GPIO29 to read VSYS voltage:

A few RP2040 GPIO pins are used for internal board functions:

• GPIO29 OP/IP wireless SPI CLK/ADC mode (ADC3) to measure VSYS/3
• GPIO25 OP wireless SPI CS - when high also enables GPIO29 ADC pin to read VSYS
• GPIO24 OP/IP wireless SPI data/IRQ
• GPIO23 OP wireless power on signal
• WL_GPIO2 IP VBUS sense - high if VBUS is present, else low
• WL_GPIO1 OP controls the on-board SMPS power save pin (Section 3.4)
• WL_GPIO0 OP connected to user LED

RP2 port now has 15 different boards. I think there is no need to add something to MicroPhyton documentation about Pico W pin usage. Documentation chapter General information about the RP2xxx port needs section "Multitude of boards" as other ports has it:

Multitude of boards

There is a multitude of modules and boards from different sources which carry the RP2xxx chip. MicroPython tries to provide a generic port which would run on as many boards/modules as possible, but there may be limitations. Raspberry Pi Ltd boards are taken as reference for the port (for example, testing is performed on them). For any board you are using please make sure you have a datasheet, schematics and other reference materials so you can look up any board-specific functions.

To make a generic RP2xxx port and support as many boards as possible the following design and implementation decision were made:

• GPIO pin numbering is based on RP2xxx chip numbering. Please have the manual/pin diagram of your board at hand to find correspondence between your board pins and actual RP2xxx pins.
• All pins are supported by MicroPython but not all are usable on any given board. For example pins that are connected to external SPI flash should not be used, and a board may only expose a certain selection of pins.

Some manufacturers maintain MicropPython ports tuned for best functionality of their boards in their own repositories. To get most functionality from such boards use firmware provided by manufacturers.

This issue can be closed after someone will add port-rp2 and doc labels and remove bug label.