nRF9151 Feather completely unresponsive after sys_poweroff()

ianjanicki

I’ve bricked my nRF9151 Feather after testing Zephyr’s sys_poweroff() and I’ve exhausted every recovery method I can find.

What happened:

Flashed a test firmware that calls sys_poweroff() with GPIO wake (DS3231 RTC alarm on P0.27). System Off + alarm wake was working correctly.
Flashed the production firmware (uses k_sleep(), does NOT call sys_poweroff()).
Connected the Arducam camera VCC to the 3.3V header pin — board immediately went dead on USB.
Briefly saw “RPI-RP2” disk notifications (BOOTSEL mode) when power cycling, but the RP2040 disconnected too fast to flash debugprobe.uf2.
After several recovery attempts, the RP2040 stopped appearing entirely. No USB enumeration at all — not as CMSIS-DAP, not as RPI-RP2, nothing.

What I’ve tried:

Every BOOTSEL sequence (BS held while plugging in, various timing)
probe-rs erase –chip nRF9151_xxAA –allow-erase-all in a tight loop
picotool load in a tight loop
Raw libusb detection + UF2 write (found device once but it disappeared before write completed)
Circuit Dojo recovery tool with 60s timeout
Pulling EN pin to GND, to 3.3V, and to VBUS — with and without battery
Full power drain (USB + battery disconnected, 60+ seconds)
All three buttons in various combinations

Board state:

No battery connected
All external peripherals disconnected (camera, DS3231 RTC)
USB cable and port confirmed working (other devices enumerate fine)
system_profiler SPUSBDataType shows zero USB devices from the board
macOS system log shows no USB attach/detach events

My (Claude’s) theory: The nPM1300 PMIC entered ship mode or a latched fault state (possibly overcurrent protection from the camera connection). The RP2040 has no power since it’s fed through BUCK1 → TPS22919, not directly from USB VBUS.

Questions:

Is there a way to force the nPM1300 out of this state without external hardware? (All I have is basic feather)
Are the SWD test pads (TP1/TP2 on the schematic) accessible for direct nRF9151 programming with an external probe?
Any other recovery method I’m missing?

Board purchased March 2026, using NCS v2.9.0.

Thanks for any help

jaredwolff

As long as you didn’t disable the code in https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers/blob/v3.2.x/boards/circuitdojo/feather_nrf9151/startup.c you have about 2 seconds to recover the board if you were disabling buck2 in your application. (which sounds like you are)

My recovery sequence for this situation is:

Have probe-rs erase --chip nrf9151_xxAA queued up in a terminal
Plug in the board to USB C
Hit the reset button
Immediately execute the above erase command

Usually that does the trick. I hope that helps!

ianjanicki

We have your board definition cloned locally (nfed repo). But didn’t use it because early on we hit build errors with NCS v2.9.0 and fell back to the Zephyr-included board def with custom overlays. I should have tried harder to make your board def work — we missed startup.c and the PMIC initialization entirely. So no, startup.c is not flashed.

The board is now completely dark — RP2040 won’t enumerate on USB in any mode. probe-rs erase + RST tapping catches nothing. Don’t have an external SWD probe. Any way to recover without one?

jaredwolff

There is no Zephyr included board def for the nRF9151 Feather. I can’t support any use of the board with anything other than the official board defs and drivers.