RP2040: Is WaveshareBoard::powerOff() intentionally a no-op?

[s465h98bft-boop]

Hi all,

I'm building a battery-powered outdoor sensor node (Companion/Tracker role)
based on the Raspberry Pi Pico + Waveshare Pico-LoRa-SX1262 shield, targeting
2 years of runtime on a single primary lithium cell.

Because the RP2040's own dormant/sleep current is still in the ~0.8 mA range
(per the RP2040 datasheet), that's too high for a multi-year battery budget.
So my plan is to use an external nanopower timer IC (TI TPL5110, ~20-35 nA)
that physically cuts all power to the board between transmissions, and
restores it either on a timer or on a sensor-triggered wake signal. The board
does a full cold boot each time, sends its message, and then the timer cuts
power again after a short delay.

My idea was to call board.powerOff() first, wait a few seconds or minutes,
and only then cut power externally. That way the firmware gets a chance to
stop the radio and finish any pending flash writes (e.g. /prefs.json,
/contacts3, /channels2, /bl/*) before power disappears.

But I checked the source, and WaveshareBoard (and XiaoRP2040Board) don't
implement powerOff() at all - it just falls back to an empty no-op in
src/MeshCore.h. ESP32 and nRF52 both have real implementations (stopping the
radio, then entering deep sleep), but I couldn't find anything similar for
RP2040 anywhere in the codebase.

Questions:

1. Is RP2040 deep-sleep/powerOff() simply not implemented yet (no one's
   gotten to it), or is there a specific reason it's not feasible on this
   platform?
2. Is anyone already working on this? If not, would a straightforward
   implementation (radio.sleep() + rp2040 dormant/sleep) be a welcome
   contribution?
3. More specifically for my use case: is there a documented/reliable way to
   know that all pending flash writes (e.g. the dirty_contacts_expiry
   debounce in MyMesh::loop()) have completed, so it's safe to fully remove
   power? Or is that something powerOff() would need to guarantee as part of
   its implementation?

I can't write the implementation myself, but I (or someone helping me) could
test a patch if pointed in the right direction.

Thanks!

[IoTThinks]

For RP2040, you are welcome to put in code to powerOff() at uA.
It should not be difficult if you / any friends have RP2040 on hand.

Until recently, ESP32 / NRF52 can powerOff() at around 10uA. Before MeshCore 1.15 or 1.16, most ESP32/NRP52 boards was powered off at...6mA.

[IoTThinks]

Are you using Seeed Studio XIAO RP2040 with Sx1262 for Xiao?
https://www.seeedstudio.com/XIAO-RP2040-v1-0-p-5026.html
https://www.seeedstudio.com/Wio-SX1262-for-XIAO-p-6379.html

Since the boards are not so commonly used, I guess we need to wait for a friend here with existing RP2040.

[s465h98bft-boop]

Not XIAO, sorry - I'm on a Raspberry Pi Pico + Waveshare Pico-LoRa-SX1262
shield (WaveshareBoard class in variants/waveshare_rp2040_lora). Same
RP2040_PLATFORM as XIAO RP2040 though, so I'd expect a dormant-mode
powerOff() implementation to be mostly board-agnostic (the RP2040 SDK
dormant-mode calls don't care which shield is attached) - probably just
needs to make sure the radio is put to sleep first via radio_driver, and
maybe board-specific pin handling if any pins need to stay in a defined
state during dormant.

One data point that might be useful context: I checked Raspberry Pi's own
app note ("Power switching RP2040 for low standby current applications")

• RP2040's best-case dormant current is ~180uA typical, not in the ~10uA
  range mentioned for ESP32/nRF52. So even a correct RP2040 implementation
  won't get as low as those platforms - just flagging that so nobody's
  surprised later.

For my use case specifically, I don't actually need dormant mode to hold
for a long time - I'm cutting power externally via a nanopower timer right
after a short (sub-second to few-second) window, so dormant mode would
mainly serve as a safe "everything's quiesced" state right before that
external cutoff, not as the main power-saving mechanism. If that's a
useful angle for the implementation, happy to describe the exact sequence
I'm thinking of.

[IoTThinks]

These combos, right?
In a few versions ahead, I may add PowerSaving support for Xiao RP2040 and sx1262 first.
The code should be similar as they use the same RP2040.

For now, hope some friends here with WaveShare sx1262 to assist.
Have a nice day.