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.

[seamusdemora]

Thanks so much!!

[seamusdemora]

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

That's very good to hear!

[seamusdemora]

RE the openocd issue:

Wow... what a goat rope this has become. I finally managed to restore some function: I can at least upload my 'INA260 Power project' file from the RPi 5 to the pico. How? I had to flash (re-flash??) the firmware in the debug probe! Even d/l the file from your GitHub site was a mystery, but finally resolved as follows:

 $ wget "https://github.com/raspberrypi/debugprobe/releases/download/debugprobe-v2.0.1/debugprobe.uf2?raw=True" -O /home/pi/debugprobe.uf2 

. . . 

Length: 84480 (82K) [application/octet-stream]
Saving to: ‘/home/pi/debugprobe.uf2’

/home/pi/debugprobe.uf2                         100%[====================================================================================================>]  82.50K  --.-KB/s    in 0.02s

2024-09-24 05:13:28 (5.26 MB/s) - ‘/home/pi/debugprobe.uf2’ saved [84480/84480]
$ 

[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)"

[seamusdemora]

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)"

Thanks - I was using the PDFs as my primary source of info. ... but may I say that passage in the README is quite confusing!?

[seamusdemora]

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

I'll certainly look into that... have you guys had many issues with openocd?

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

No can do - was banned "for life" for the infraction of standing up to dictators :)

[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.

[seamusdemora]

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.

"banned for perfectly valid reasons"?!?! Because I had an issue with hardware I bought from the company you work for?

Listen James - IIRC, it was you who were throwing your weight around, acting like Mr. Big Shot, and damning me because I had a complaint about the faulty hardware that I bought from RPi... Then, you demanded that I shut up! I had a legitimate complaint - your trying to silence me is not the way "Customer Service" is supposed to be handled. At least not in reputable companies.

[seamusdemora]

@kilograham

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

Hello Graham - I wondered if you had an approximate date for bringing the sleep and dormant examples into the "mainstream"? Curious as I'm apparently going to have to rebuild my development setup in an effort to cure the OpenOCD issues. Thanks for any insight.

[seamusdemora]

@kilograham

Pull in PICO SDK (must be before project)

include(pico_sdk_import.cmake)

We also need PICO EXTRAS

include(pico_extras_import.cmake)

Graham, IAW your suggestion, my revised file: ~/pico/sleep_dormant/CMakeLists.txt is below:
Does it look OK to you?

cmake_minimum_required(VERSION 3.25)
include(pico_sdk_import.cmake) 
# NOTE change required to location
include(/home/pi/pico/pico-playground/pico_extras_import.cmake)
project(sleep_dormant_project C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
pico_sdk_init()
add_executable(sleep_dormant
        sleep_dormant.c
        )
target_link_libraries(sleep_dormant pico_stdlib hardware_sleep)

if (PICO_CYW43_SUPPORTED)
    target_link_libraries(sleep_dormant pico_cyw43_arch_none)
endif()

# this enables stdio via minicom via usb, and uart support
pico_enable_stdio_usb(sleep_dormant 1)
pico_enable_stdio_uart(sleep_dormant 1)

# create map/bin/hex file etc.
pico_add_extra_outputs(sleep_dormant)

And here's the (slightly) modified hello_dormant.c from pico-playground:

note: It's been re-located to ~/pico/sleep_dormant

#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/sleep.h"

int main() {
    stdio_init_all();
    printf("Hello Sleepy Dormant!\n");

    printf("Switching to XOSC\n");
    uart_default_tx_wait_blocking();

    // UART will be reconfigured by sleep_run_from_xosc
    sleep_run_from_xosc();

    printf("Running from XOSC\n");
    uart_default_tx_wait_blocking();

    printf("XOSC going dormant\n");
    uart_default_tx_wait_blocking();

    // Go to sleep until we see a high edge on GPIO 10
    sleep_goto_dormant_until_edge_high(10);
/*  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    RE the "high edge on GPIO 10":
    GPIO 10 is AKA pin 14 on the Pico
    ---------------------------------------------------------------------------
    Source of "high edge":
    Implemented via GPIO pin on RPi5: GPIO23 (pin 16) via dtoverlay:
    dtoverlay=gpio-led,gpio=23,label=mytimerled
   and delivered via:
   ```bash
      $ cd 
*/

    uint i = 0;
    while (1) {
        printf("XOSC awake %d\n", i++);
    }

    return 0;
}

The make -j2 looks good now (after the change noted above to CMakeLists.txt)

$ pwd
~/pico/sleep_dormant/build
$ make -j2
PICO_SDK_PATH is /home/pi/pico/pico-sdk
Target board (PICO_BOARD) is 'pico'.
Using board configuration from /home/pi/pico/pico-sdk/src/boards/include/boards/pico.h
Pico Platform (PICO_PLATFORM) is 'rp2040'.
Build type is Release
TinyUSB available at /home/pi/pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
BTstack available at /home/pi/pico/pico-sdk/lib/btstack
cyw43-driver available at /home/pi/pico/pico-sdk/lib/cyw43-driver
lwIP available at /home/pi/pico/pico-sdk/lib/lwip
mbedtls available at /home/pi/pico/pico-sdk/lib/mbedtls
Using PICO_EXAMPLES_PATH from environment ('/home/pi/pico/pico-examples')
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/pico/sleep_dormant/build
[  1%] Built target bs2_default
[  3%] Built target bs2_default_padded_checksummed_asm
[  4%] Building C object CMakeFiles/sleep_dormant.dir/sleep_dormant.c.obj
[  5%] Linking CXX executable sleep_dormant.elf
[100%] Built target sleep_dormant

Using OpenOCD to write the sleep_dormant.elf file to the Pico

Please note that I am using the same openocd parameters here as I do in my other project (INA260_trial; which works well) - except for the .elf filename.

$ sudo openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "program sleep_dormant.elf verify reset exit"
Open On-Chip Debugger 0.12.0-g4d87f6d (2024-02-11-10:09)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

Info : Hardware thread awareness created
Info : Hardware thread awareness created
adapter speed: 5000 kHz

Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6633861A385812C
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
** Programming Started **
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors

Info : Padding image section 1 at 0x10008470 with 144 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x10008500 .. 0x1000ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error: Failed to select multidrop rp2040.dap1
Error: Failed to connect multidrop rp2040.dap1
Warn : Connecting DP: stalled AP operation, issuing ABORT
Error: [rp2040.core1] DP initialisation failed
in procedure 'program'

Some observations:

1. The openocd failure seems to have spread

After the failure above, I could no longer use openocd to write the INA260_trial elf file to the Pico :

$ sudo openocd -d2 -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "program INA260_trial.elf verify reset exit"
Open On-Chip Debugger 0.12.0-g4d87f6d (2024-02-11-10:09)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 0

adapter speed: 5000 kHz

Error: Failed to connect multidrop rp2040.dap1
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

2. The openocd failure seems to have caused the BOOTSEL method of loading a file to fail.

Repeated attempts at un-plugging the Pico from the Pi 5, pressing the BOOTSEL button & holding while re-plugging now no longer work. Running lsblk --fs failed in every case to show a device/drive for the Pico. This was on a new-out-of-the-box Pico (and Debug Probe).

A RESET to the Pico (Pin 30/RUN-to-Gnd) FOLLOWED BY a cold boot to the RPi 5 (sudo halt, pull power, re-insert power) was required to restore function. Even the Pico RESET and the cold boot didn't fix the openocd issue. Getting openocd back on track ALSO required that I load the INA260_trial.uf2 via the BOOTSEL procedure (after the RESET and cold boot) before it began working again. Only then was I able to re-load the INA260_trial.elf file via openocd! Wow...

This also seems to have caused minicom to no longer use ttyACM0 - it has now moved to ttyACM1?!

I've now invested many hours and about $30 (for new Pico & Debug probe) troubleshooting this hello_dormant example. It still not only fails to work - but seems to trash something in the Pico - or maybe in my RPi 5 development environment(?).

I wonder what is going on???

[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)