We have code that puts the HW to sleep. On a nRF52833.
The pseudo code would be something like this -
<shutdown SD, stop freertos scheduler, stop interrupts, power down all hardware blocks, put GPIOs into low power state (most inputs, some gate our HW>
If at this point we call a NRF_POWER->SYSTEMOFF = 1; we see the board consumption drop to ~6uA (which is about what we expect)
If however we try either a loop around nrf_pwr_mgmt_run(); or a basic
_disableirq(); while(1) { __WFI() }; // as expected this never returns
We see about 1.4mA after the main code has been running, and only 6uA if the sleep code is called immediately after HW init.
The assumption is that PMU is keeping lots of the device powered up and active.
Q. I cannot see any central method of determining the state of the PMU and which peripherals are powered up, is this correct?
To remove any ambiguity on our shutdown code I added in a simple function "force_all" see below
and called it before the sleep, it had no effect.
So, to recap, if the power down code is called after all the HW is initialized we see the expect 6uA (with either a WFI() loop or a complete core shutdown) - if we call it after the application has been running we see 1.4mA on the WFI() loop and 6uA on the shutdown. Therefore I assume the issue is something still running on the device.
I assume there is a hole in my shutdown logic, or something is somehow being determined as "ON" by the PMU and is keeping everything else on. And 1.4mA is fairly large as things go.
I've been diving the forums for a few hours, and other that "check your peripherals are all off" (see force_all() above) there it not a huge amount of advice on debugging the PMU to see where the power is going. The FW has vanished into a WFI() and (according to the Segger has never returned - after all, all interrupts are disabled).
it would not be possible to recreate all of this as an example, but I can certainly include shutdown code.
I know the Segger being attached powers up a large amount of the core via the SWD - so I remove it when not checking if the WFI() is returning and I see a drop of about ~30uA only.
The intention is that once I have solved this power issue I'll re-enable a single RTC via the LFCLK to allow it to make decisions and come out of sleep.
Any advice welcome.
