Low Power modes - Do they actually work?

[seamusdemora]

Personal experience w/ Pico:
I've read (most of) the documentation, and posted a couple of pico-related issues here on github. I've also built several of examples, and have successfully "used" a couple of the i2c examples to create a fully functional Pico application/library that controls an INA260 "Power Monitor".

I use the Pico C SDK almost exclusively in my development; I have used the Earl Philhower Arduino-Pico environment to help me understand a few things wrt I2C. The Pico SDK is installed on my RPi 5 (bookworm Lite), and I do everything from there. I do not use any of the "VS" stuff (quit MS years ago, and ain't goin' back!), GUIs, etc.

My Issue:
Based on my "success" with the INA260, I'm interested in using the Pico (2040) in an "off-grid" application; i.e. a small solar cell & battery, in a remote location).

Unfortunately, I can't seem to reach "second base" in this endeavor. I have been able to successfully compile and run the "hello_dormant" example in "pico-playground", but I've been unable to set it up as a stand-alone app as described in the section "Manually Create your own Project" of the "Getting Started ..." guide. I do not know what I am missing exactly!

I gather the delegation of sleep and dormant to the 'pico-playground' and 'pico-extras' repos is due to their "NRPT" (Not Ready for Prime Time) status?? But the sleep and dormant examples have been in this state for 3 years now according to the GitHub stats! Isn't it about time these examples were "fleshed out and documented"? Frankly, this makes me wonder if the issues are a failing of the low power facilities of the RP2040 - or workload of the RPi staff?

Not to nit pick, but there are what seem to be clear issues in the documentation:

From: raspberry-pi-pico-c-sdk-2024-08-21.pdf, para '4.2.1.3.2. aon_timer_enable_alarm':
On RP2040 The alarm will not fire if it is in the past On RP2040 The alarm will fire if it is in the past

How about it then?... Will the sleep and dormant examples be brought out of the purgatory of 'pico-playground' and 'pico-extras' any time in the near future? And I would really appreciate some help in the meantime on how to set up these examples outside that purgatory; i.e. in ~/pico/MySleepAndDormantProject.

Thanks for listening.

[kilograham]

They are indeed coming soon - they didn't quite make it in with SDK2.0.0

In the meanwhile, you need to include pico_extras in your project as that's where hardware_sleep is

So, something like

# Pull in PICO SDK (must be before project)
include(pico_sdk_import.cmake)

# We also need PICO EXTRAS
include(pico_extras_import.cmake)

[lurch]

Not to nit pick, but there are what seem to be clear issues in the documentation:

From: raspberry-pi-pico-c-sdk-2024-08-21.pdf, para '4.2.1.3.2. aon_timer_enable_alarm':
On RP2040 The alarm will not fire if it is in the past On RP2040 The alarm will fire if it is in the past

Looks like that was a typo, well spotted. raspberrypi/pico-sdk#1945 should fix that.

[lurch]

I know openocd is not an RPi product, but hoping you can offer some advice.

You probably ought to open an issue on https://github.com/raspberrypi/openocd

You could also try asking for help at https://forums.raspberrypi.com/

[lurch]

Uh - where do those changes go exactly? I tried adding them to ~/pico/sleep_dormant/CMakeLists.txt, but here's the result:

https://github.com/raspberrypi/pico-extras/blob/master/README.md says "(copying external/pico_extras_import.cmake into your project)"

[JamesH65]

I double checked and looked at that thread; you were banned for perfectly valid reasons. Very few rules on the forum as well, so well done.

[kilograham]

Note you are powering down the chip (including the debug h/w) while you are debugging it, which isn't going to go particularly well.

This is causing your openocd errors

Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT

You are also powering down the chip while it has an active USB connection to the host (since you are using stdio USB) - it seems like this has borked your Linux USB stack, hence the need to reboot - this is a Linux bug, and happens occasionally (i suspect not every time)

[kilograham]

cc @peterharperuk

[kilograham]

This issue has veered very much off into the "how do I?" "why doesn't it?" realm which really belongs in the forums

I am keeping this issue open and copying @peterharperuk as a reminder for the upcoming SDK release with new sleep examples, which will be good, since the ones you are using in pico_playground/pico_extras aren't "supported" anyway

[lurch]

If you have any suggestions for recovering from such a failure, I'd appreciate it if you could share that.

As I already mentioned elsewhere, see https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html#resetting-flash-memory

[peterharperuk]

There are updates to the sleep in pico-extras here raspberrypi/pico-extras#79
and to pico-playground here raspberrypi/pico-playground#48

I'll add a readme about openocd explaining that the device will be unresponsive when it's dormant. The examples wakeup for 10s and that gives openocd enough time to reconnect and allow a debug session to continue.

[lurch]

If it took you 6 attempts to enter BOOTSEL mode, then I can only assume that you were doing it wrong.

1. Unplug everything from your Pico
2. Hold down the BOOTSEL button
3. With the BOOTSEL button held down, insert the MicroUSB cable to the Pico
4. Wait for the Pico to be recognised as a mass-storage device by your PC
5. Release the BOOTSEL button
6. Drag'n'drop (or copy'n'paste) the required UF2 file onto the RPI-RP2 drive
7. Pico will automatically reboot and start running the new code