Unable to measure VSYS/ADC3/GPIO29 with WIFI

[pspeybro]

I have a setup with Pico W + pimoroni lipo shim.
I am trying to run it on batteries, measure some sensors and submit the data via wifi.
I am also trying to check battery status from time to time to get an idea when charging is needed. There is a micropython example here, but I found that this also does not work for Pico W.

I also looked on this forum thread where others also struggle with doing this with python in combination with using WIFI.
https://forums.raspberrypi.com/viewtopic.php?p=2078340#p2078340 (my username = Darkness)

I am trying to accomplish this using the SDK.

From the datasheet:
`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
WL_GPIO2 IP VBUS sense - high if VBUS is present, else low

Due to pin limitations, some of the wireless interface pins are shared. The CLK is shared with VSYS monitor, so only
when there isn’t an SPI transaction in progress can VSYS be read via the ADC. The Infineon CYW43439 DIN/DOUT and
IRQ all share one pin on the RP2040. Only when an SPI transaction isn’t in progress is it suitable to check for IRQs. The
interface typically runs at 33MHz`

So it is clear that due to pins being shared with the wifi chip, it is not possible to measure VSYS using GPIO29+GPIO25.

• is there a way to know if an SPI transaction is in progress or not to make sure an ADC3 measurement can be done?
• Is there a reliable way to repeatedly enable and disable wifi to make GPIO29 and GPIO25 available? I tryied calling cyw43_arch_deinit() but afterwards cyw43_arch_init() seems to fail and hang the pico.
• is cyw43_arch_gpio_get(2); the correct way to read WL_GPIO2/VBUS sense? pico_w.h does not contain a definition for these pins, unlike the #define CYW43_WL_GPIO_LED_PIN 0

This seems like a very common use case, so an example would be very useful for the community.

[kilograham]

cc @dp111

[peterharperuk]

is there a way to know if an SPI transaction is in progress or not to make sure an ADC3 measurement can be done?
Is there a reliable way to repeatedly enable and disable wifi to make GPIO29 and GPIO25 available?

Hi. If you're writing C code using pico-sdk, you shouldn't really need to know when a SPI transaction is in progress or disable WIFI. We set the chip select low when we're using SPI to talk to the wifi chip and then set it high again when we're done. If you want to read VSYS then you just need to make sure we don't do any wifi stuff while you're using GPIO29_ADC. You should be able to do this by wrapping your use of GPIO29_ADC with the CYW43_THREAD_ENTER / EXIT macros?

I'm not sure this helps a lot with Micropython - I'll have to think about that, and read the forum thread.

is cyw43_arch_gpio_get(2); the correct way to read WL_GPIO2/VBUS sense?

I can add a #define for the gpio if it helps. (later: edited, you're fine to call this inside CYW43_THREAD_ENTER / EXIT)

This seems like a very common use case, so an example would be very useful for the community

Yes, good point raspberrypi/pico-examples#324

[peterharperuk]

Maybe we should support a rp2.read_vsys method in Micropython?

[pspeybro]

I'm just using C or C++, not micropython. It's just the pimoroni example and forum thread that are using micropython.

I will try with the CYW43_THREAD_ENTER / EXIT. I did not encounter these before. Are they explained somewhere in the datasheet or documentation?

Also, do I need to pull GPIO25 high to read GPIO29_ADC?

An extra #define is not strictly necesary, but because the datasheet refers to WL_GPIO2 and micropython seems to define that, it might be useful if those WL_GPIO1 and WL_GPIO2 are also defined, so that you do not need to guess that these just correspond to 1 and 2.

I was considering making an issue in the example repo, so thank you for doing that. If I get my test working, I will post the code there.

[peterharperuk]

Also, do I need to pull GPIO25 high to read GPIO29_ADC?

I haven't tested it yet but it has to be high (famous last words) while we're not doing anything with wifi or else a spi transaction would be ongoing? You might have to change the function of gpio 29 while you're reading from it and restore it before calling
CYW43_THREAD_EXIT.

I did not encounter these before. Are they explained somewhere in the datasheet or documentation?

There's some discussion in the examples of using this for for networking w.r.t. cyw43_arch_lwip_begin. In the latest sdk (soon to be released) there's a new asynchronous api that has an explicit lock function which might be more obvious.

Out of interest, what "method" are you using to build your code? I'm guessing you're linking to pico_cyw43_arch_lwip_threadsafe_background? If you use "poll" you shouldn't even need the lock.

[pspeybro]

Out of interest, what "method" are you using to build your code? I'm guessing you're linking to pico_cyw43_arch_lwip_threadsafe_background? If you use "poll" you shouldn't even need the lock.

Indeed, I am using pico_cyw43_arch_lwip_threadsafe_background, as I was under the impression that polling is generally less efficient, but I did not read up on that in detail yet...

[kilograham]

cyw43_thread_enter() and cyw43_thread_exit() are nominally better (but equivalent to CYW43_THREAD_ENTER and CYW43_THREAD_EXIT

still seems that neither are particularly documented.

[pspeybro]

That cyw43_thread_enter()/cyw43_thread_exit() definitely seems to improve things. (requires #include "pico/cyw43_arch/arch_threadsafe_background.h")

Checking VBUS/WL_GPIO2 seems to correctly indicate whether powered from usb or battery.

Initializing the ADC3 between the enter/exit seems to work as well and no need to set GPIO25 high.

Below is the log from the data submitted via wifi to my api. Capacitive moisture sensor on ADC2, 1-wire temperature sensor, VSYS and VBUS

[2023-37-06 22:37:41] Moisture: 2,491, Temperature: 20,5, Voltage: 4,981, Vbus: 1 <- USB
[2023-37-06 22:37:43] Moisture: 2,486, Temperature: 20,5, Voltage: 4,984, Vbus: 1 <- USB
[2023-37-06 22:37:45] Moisture: 2,49, Temperature: 20,5, Voltage: 4,123, Vbus: 0 <- Battery
[2023-37-06 22:37:46] Moisture: 2,49, Temperature: 20,5, Voltage: 4,123, Vbus: 0 <- Battery
[2023-37-06 22:37:48] Moisture: 2,49, Temperature: 20,5, Voltage: 4,126, Vbus: 0 <- Battery
[2023-37-06 22:37:50] Moisture: 2,49, Temperature: 20,5, Voltage: 4,984, Vbus: 1 <- USB
[2023-37-06 22:37:52] Moisture: 2,489, Temperature: 20,5, Voltage: 4,979, Vbus: 1 <- USB

Vbus is nicely going to 0 when unplugging usb, and the voltage (VSYS/GPIO29_ADC ) measurement goes from 4.98 to 4.12 when switching to battery. This way I can skip reading the VSYS when connected via USB.

We do need to restore the GPIO29_ADC setting back to the wifi settings. After checking the pin settings during wifi and ADC, it seems I need to set the function back to USB and pull down (though the pull down did not seem necessary)
gpio_set_function(29, GPIO_FUNC_PIO1); //7
gpio_pull_down(29); //does not seem necessary, but this way it is back to how it was before adc_gpio_init(29);

I will clean up my code a little bit and post it in the example issue

Thank you very much for the hints!

[pspeybro]

Pull request with example code: raspberrypi/pico-examples#326

[liaan]

Hi, Apologies first, I have no knowledge of micropython. But was wondering, can one not have a interrupt Lising on the CS going high (wifi not communicating), Set pin 29 to analogue, read, revert, and then continue?

Not sure how interrupt priorities work with micropython, might be a option?

[peterharperuk]

It's the same on MP except you have to use pendsv_suspend / pendsv_resume instead of cyw43_thread_enter / cyw43_thread_exit. Thus my suggestion that we add a rp2 method to read vsys as reading the gpio from MP won't take the lock. I don't much fancy exposing the lock in MP.