RAK3401: powerOff() override + AIN button LPCOMP wake from SYSTEMOFF 🤖🤖

[disq]

Two board-level pieces from @dorfman2's #2414 that are useful for any RAK3401 firmware, not just the repeater variant that PR targets.

What this changes

1. RAK3401Board::powerOff() override (variants/rak3401/RAK3401Board.h) — routes _board->powerOff() through initiateShutdown(SHUTDOWN_REASON_USER) so the shutdown reason is properly tagged in GPREGRET2 instead of falling through to the base class default.

2. AIN button wake-from-SYSTEMOFF via LPCOMP (variants/rak3401/RAK3401Board.cpp) — when an env defines PIN_USER_BTN_ANA, arm a wake source before entering SYSTEMOFF so pressing the button powers the board back on.

3. NRF52Board::configureVoltageWake() gains a detect_down flag (src/helpers/NRF52Board.{h,cpp}) — defaults to false (the existing upward-crossing voltage-recovery behavior, so no other NRF52 board is affected), and true selects a downward crossing for the button wake.

Why LPCOMP and not GPIO SENSE

#2414's original code armed the pin with SENSE_Low. That works for the repeater, where the button is a digital normally-open switch to GND. It does not work on the companion_radio build, where the same pin (PIN_USER_BTN_ANA=31, P0.31 = AIN7) is wired as an analog button — MomentaryButton reads it as analogRead() < threshold.

Two failures, both reproduced and verified on hardware (companion_radio_ble, on USB and battery):

• Shutdown hung. The release-wait used digitalRead() on this pin, but the SAADC leaves the digital input buffer disconnected, so digitalRead() always returns LOW. The loop never exited, SYSTEMOFF was never reached — screen off, but BLE/serial still alive.
• Immediate self-wake. Even past that, GPIO SENSE_Low reads this line as LOW at the released idle level (analogRead reports ~VDD while NRF_GPIO->IN reads 0 and the SENSE latch re-asserts the instant it's cleared), so the chip woke the moment it entered SYSTEMOFF. RESETREAS = Wake from GPIO (0x10000), identical on USB and battery — ruling out VBUS.

The fix arms LPCOMP instead. It operates in the analog domain, so it sees the idle level correctly: a DOWN crossing at ~½ VDD wakes on a press (released idles near VDD = above threshold; a press pulls the pin to ~0V = below). The release-wait now uses analogRead and is bounded by a 5s timeout so a stuck reading can never wedge shutdown. LPCOMP is otherwise unused for a USER shutdown (voltage wake is only armed for the low-voltage / boot-protect reasons), so there is no conflict. The AIN channel and threshold are overridable build defines.

What this does NOT include

The repeater-specific UI redesign, status screen, and simple_repeater/main.cpp button handler from #2414 are out of scope here — the companion_radio UI tree already has its own button handling in examples/companion_radio/ui-new/UITask.cpp. This PR cleanly lifts only the universally-beneficial board-level pieces; #2414 can land independently with the repeater UI work on top.

Testing

Verified on RAK3401 + RAK19007 + companion_radio_ble build, on both USB and battery:

• _board->powerOff() from the companion UI menu enters SYSTEMOFF and the board stays off (USB/serial drop, BLE LED dark).
• Pressing the AIN button wakes the board; RESETREAS = Wake from LPCOMP and the subsequent boot is normal.
• RAK_3401_repeater (no PIN_USER_BTN_ANA) and RAK_3401_companion_radio_ble both build clean; the configureVoltageWake() signature change is backward-compatible via the defaulted parameter.

🤖 Generated with Claude Code

[dorfman2]

Ah @disq I see what you meant now. I was too focused on the UI portion of the code. Would love to see this implemented!

[disq]

The other PR wakes immediately and I put it to draft while I investigate, so I need to test this again first.
Now tested successfully.

[disq]

@dorfman2 It wasn't working for me on the companion so had to burn more tokens and do the "right thing".