Low Power modes - Do they actually work?

seamusdemora commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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. https://github.com/raspberrypi/pico-sdk/pull/1945 should fix that.

seamusdemora commented 2 months ago

Thanks so much!!

seamusdemora commented 2 months ago

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

That's very good to hear!

seamusdemora commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

@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 commented 1 month ago

@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 commented 1 month ago

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)

seamusdemora commented 1 month ago

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. @kilograham

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)

I have to confess I'm not entirely clear on what you're saying... It has occurred to me that part of my problem is that I am putting the Pico into a 'dormant' state, and expecting it to "do something". So yeah, perhaps I am guilty. But there must be a point to this example code?!

WRT "debug h/w" & "debugging" in general: I'm not trying to "debug" - as in single-stepping through instructions, using gdb, etc. I am strictly using the Debug Probe and openocd as a means to avoid using the 3-handed BOOTSEL procedure, and get access to the Pico serial output. Apologies if that was not clear.

I've assumed some things about how openocd loads the .elf file: I assumed it wrote the file to flash, and then quit; and only then - after it had finished loading the code - did execution begin. Is it doing something else? Is that why I get the warnings and errors?

Should I be loading the binary (uf2) file via BOOTSEL instead of openocd? Or perhaps I should ask the question this way: "How should I load and run this example?"

As I understand the sleep_dormant.c code, I should get some output before the 'dormant' mode is invoked. I've also set up an "interrupt" to Pico GPIO 10 from Pi5 GPIO 23. But in all the times I've tried, this has never shown any effect at all; I expected the Pico to wake, and begin outputting XOSC awake 1, XOSC awake 2, etc - forever. But that has never happened - even when I have loaded the sleep_dormant.uf2 file via BOOTSEL.

I would be forever grateful if you could please explain how I should load the compiled program, and what I should expect to see. For example:

Should I load the code via BOOTSEL instead of using openocd & Debug Probe - or some other way?
Should I expect to see any output from the code listing above in my minicom terminal?
Should I be able to "wake" the Pico (end the dormant state) as I've assumed?

kilograham commented 1 month ago

cc @peterharperuk

seamusdemora commented 1 month ago

My Pico is an RP2040 - or Pico 1. The board silkscreen says, "Raspberry Pi Pico H".

I've just noticed something that may be relevant: When I perform the BOOTSEL procedure, and cat the file INFO_UF2.TXT, here's what is shown:

$ cat /mnt/pico/INFO_UF2.TXT
UF2 Bootloader v3.0
Model: Raspberry Pi RP2
Board-ID: RPI-RP2

I did read the passage in the "Getting Started Guide" that said:

The SDK builds binaries for the Raspberry Pi Pico 2 by default. To build a binary for a different board, pass the -DPICO_BOARD= option to CMake, replacing the placeholder with the name of the board you’d like to target. To build a binary for Pico 2, pass -DPICO_BOARD=pico2. To build a binary for Pico W, pass -DPICO_BOARD=pico_w. You can specify a Wi-Fi network and password that your Pico W examples should connect to, by passing -DWIFI_SSID="Your Network" -DWIFI_PASSWORD="Your Password" too

I think I raised a question about this paragraph previously, but got no answer... and since things were working for my INA260 project, I assumed the paragraph contained another typo. Why did I think there was a typo? There are two identically worded notes on pg 35 & 39. One says the default is Pico 2, but the other claims the default is Pico 1!

Anyway - could this be the cause of all of my problems?

If so, can someone please explain WHAT the option for Pico 1 is, and HOW to "pass the option to CMake"??

kilograham commented 1 month ago

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

seamusdemora commented 1 month ago

@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

Graham,

As I explained earlier, I cannot use the forums as I was "banned for life" a few years ago.

Thanks for calling some additional help here, but what do you think about the board I'm building for? I've just now found that the Getting Started Guide has two different versions of the note I quoted above: one on p. 35, the other on p. 39. They say the opposite of one another. If this is a board issue only, and you could help me with an answer then I'll be out of your hair - for a while anyway.

WRT "aren't supported": Does this mean they don't work at all?

seamusdemora commented 1 month ago

@kilograham

Earlier this evening, I ruined my second Pico on this sleep_dormant project. By "ruined" I mean it appears to be irrevocably broken/bricked/whatever. I reached the point where OpenOCD issued its ** OpenOCD init failed ** repeatedly on the "good/stable" INA260 project. I did 6 or 7 cold reboots (sudo halt, pull power, reconnect power), then did a RESET (RUN pin to GND) after boot, but the ** OpenOCD init failed ** was constant; it did not change.

I replaced the Pico board with a new one (luckily I ordered two!), booted, and openocd began servicing my INA260 project successfully again.

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

Otherwise, my plan is to contact the merchant for a replacement or refund... unless Raspberry Pi would like to buy them for a post mortem :)

I think I'm done with this sleep/dormant stuff on the Pico, so feel free to close this issue if you like. However, I do feel that the hello_dormant (and maybe the hello_sleep) examples should have a suitable WARNING added. (Just my two pence)

lurch commented 1 month ago

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 commented 1 month ago

There are updates to the sleep in pico-extras here https://github.com/raspberrypi/pico-extras/pull/79 and to pico-playground here https://github.com/raspberrypi/pico-playground/pull/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.

seamusdemora commented 1 month ago

@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

I'm sorry if I forgot about this.

I did read the link this time:

Resetting Flash memory Pico’s BOOTSEL mode lives in read-only memory inside the RP2040 chip, and can’t be overwritten accidentally. No matter what, if you hold down the BOOTSEL button when you plug in your Pico, it will appear as a drive onto which you can drag a new UF2 file. There is no way to brick the board through software. However, there are some circumstances where you might want to make sure your Flash memory is empty. You can do this by dragging and dropping a special UF2 binary onto your Pico when it is in mass storage mode.

That makes perfect sense to me. Unfortunately, it does not work exactly as claimed. I re-installed the Pico I thought I had bricked, and I've included below the sequence I went through to recover it. Please note the time stamps in the shell session. The first step below was to run openocd in an effort to install the sleep_dormant.elf code (the source is listed in an earlier comment above):

01:50 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ 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'

02:10 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ lsblk --fs
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs 146B-AD94                             444.9M    13% /boot/firmware
└─nvme0n1p2 ext4   1.0   rootfs ece25014-1cd7-4874-9bfc-f91e486bc000    365G     2% /

02:14 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ # BOOTSEL FAILED TO YIELD A USB DEVICE HANDLE; LET'S TRY AGAIN...

02:15 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ lsblk --fs
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs 146B-AD94                             444.9M    13% /boot/firmware
└─nvme0n1p2 ext4   1.0   rootfs ece25014-1cd7-4874-9bfc-f91e486bc000    365G     2% /

02:16 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $  # BOOTSEL FAILED (AGAIN, 2nd time) TO YIELD A USB DEVICE HANDLE; LET'S TRY AGAIN...

02:17 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ lsblk --fs
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs 146B-AD94                             444.9M    13% /boot/firmware
└─nvme0n1p2 ext4   1.0   rootfs ece25014-1cd7-4874-9bfc-f91e486bc000    365G     2% /

02:18 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ # BOOTSEL FAILED (AGAIN, 3rd time) TO YIELD A USB DEVICE HANDLE; LET'S TRY AGAIN...

02:19 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ lsblk --fs
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs 146B-AD94                             444.9M    13% /boot/firmware
└─nvme0n1p2 ext4   1.0   rootfs ece25014-1cd7-4874-9bfc-f91e486bc000    365G     2% /

02:20 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ # BOOTSEL FAILED (AGAIN, 4th time) TO YIELD A USB DEVICE HANDLE; LET'S TRY AGAIN...

02:21 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ lsblk --fs
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs 146B-AD94                             444.9M    13% /boot/firmware
└─nvme0n1p2 ext4   1.0   rootfs ece25014-1cd7-4874-9bfc-f91e486bc000    365G     2% /

02:22 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ # BOOTSEL FAILED (AGAIN, 5th time) TO YIELD A USB DEVICE HANDLE; LET'S TRY AGAIN...

02:22 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ lsblk --fs
NAME        FSTYPE FSVER LABEL   UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
└─sda1      vfat   FAT16 RPI-RP2 000A-E613
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs  146B-AD94                             444.9M    13% /boot/firmware
└─nvme0n1p2 ext4   1.0   rootfs  ece25014-1cd7-4874-9bfc-f91e486bc000    365G     2% /

02:23 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ # BOOTSEL SUCCEEDED ON THE 6th try IN YIELDING A USB DEVICE HANDLE !!!

02:25 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ # IMHO: THIS IS NOT WHAT THE DOCUMENTATION WOULD LEAD ONE TO EXPECT

02:26 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $ # NOW, TRY OPENOCD USING THE GOOD/WELL-BEHAVED INA260 PROJECT; RESULT: \
       # WAS SUCCESSFUL, BUT SERIAL PORT CHANGED TO ttyACM1 ?!
02:36 : raspberrypi5 : ~/pico/sleep_dormant/build
pi $

PLEASE NOTE TWO THINGS:

openocd ran from the command line immediately after restoring the Pico that I thought was irrevocably broken. I did not use the flash_nuke.uf2! It seems that the mere passage of time cured whatever was causing openocd to fail repeatedly (many, many times) last night.
The fact that six (6) BOOTSEL attempts were required before success is a bit troubling to me. Based on the reassurances given in the "Resetting Flash memory" section, I don't understand why six tries were required. No need to respond to this comment; I just wanted to get it "on the record".

FINALLY:

Thank you for you patience, and thanks for bringing my Pico back from the bin! :)

seamusdemora commented 1 month ago

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

Peter,

Thanks for the updates - I'll take a look at those when I've got a few minutes. And since this thread is now closed, I'll open a new one if I have questions re the modified sleep/dormant project.

Just so we're clear: I was never doing any "debugging"... my only motivation for using openocd and the 'Debug Probe' was strictly to avoid the 3-handed BOOTSEL procedure.

====== after reading the updates...

I'm now confused about something. The problem I reported here was WRT a very slightly modified version of the hello_dormant project. One of your mods seems to be applied to the hello_sleep example, and the other one doesn't appear to address anything in the hello_dormant project.

The dormant example sends some output to the serial port before going dormant. Also, the signal to 'wake' for the dormant example is a pos-going edge at GPIO 10. In my experience:

openocd never successfully completed a transfer of the .elf file from the RPi5 to the Pico
when I used BOOTSEL to upload the .uf2 file, I never got any output from minicom via the serial port (through the Debug Probe)
when I applied the pos-going edge at GPIO 10, nothing ever happened.

Consequently, I have to ask you, "Are these changes you've proposed going to make the `dormant` example work at last?

lurch commented 1 month ago

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

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

seamusdemora commented 1 month ago

@lurch

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

I did have the Debug Probe plugged in... if that made the difference, I'm surprised.

I'm not using a PC - I'm using an RPi 5/Lite, which I run via SSH from a Mac. AFAIK, there's no way to tell whether or not the Pico is "recognized" until I run lsblk. I gave it maybe 2-3 seconds, and that has always worked before... that is, before I ran into the confusion w/ the dormant example, and the openocd balking.

And once I got the dev/sdX1 device recognized, I followed the "Getting Started Guide", and had no problems:

$ sudo cp sleep_dormant.uf2 /mnt/pico
$ sudo sync
$

raspberrypi / pico-feedback