Hello Devzone,
While developing an nRF9160 based, battery powered device (working on the firmware piece of the puzzle) I have run into a couple of issues in my effort to reach a deep sleep mode and floor current of four micro-amps (4uA) or less. I am within about a current use factor of six, but only so when I disable Zephyr RTOS' power management option in my project's prj.conf file.
I am building against ncs v1.6.1, which includes Zephyr 2.6.0.
The firmware app by which I can reach floor current of about 22uA turns off UARTs of the 9160 (turns off high speed clocks used by UART RX pins), and does not explicitly set Zephyr `PM` symbol. The result is that power management for run-time hardware config changes is disabled.
When I enable Zephyr's `PM` symbol, floor current rises from ~22uA to about 45uA.
Question (1) what elements of Zephyr's Power Management feature draw about 25uA of current?
The demo code which for us achieves the lowest floor currents, on both nRF9160DK board and our custom board, is very limited in its functionality. It is a low power Zephyr demo with nearly every peripheral and Zephyr RTOS feature turned off. In real life we need to exercise UARTs and other peripherals some fraction of the time. We would like to turn things on via firmware, run for a while, then return to deep sleep mode. But so far only Zephyr's Power Management of `PM` feature allows us to turn UART clocks on and off at will. Yet to enable power management, e.g. set CONFIG_PM=y we find our floor current increase in the deep sleep configuration we're able to achieve. This is a problem.
For battery life requirements we need and want to have dynamic power management (Zephyr 'PM') and yet reach the single microamp floor currents of and in the nRF9160.
Searching Zephyr tree sources for its release tag 2.6.0, I see that CONFIG_PM symbol pulls in a couple of source files to Zephyr's build process: ./subsys/pm/power.c and ./subsys/pm/pm_ctrl.c, and possibly ./soc/arm/nordic_nrf/nrf91/power.c. It looks like one of these files enables a timer in the application processor. I'm wondering whether such a time draws the extra current we observe. And if yes, I wonder whether there is a config or programmatic way to dynamically disable that timer.
Question (2) Is there some finer Zephyr PM configuration we can apply, so that the power management feature can itself be put to sleep temporarily and awake on next entry of hardware plus firmware into full active mode?
To rewrite parts of Zephyr source tree does not seem like a reasonable way to achieve and enjoy practical, battery supporting low power operation of the nRF9160. Hoping there is some experience and perhaps even a vetted solution or example in the public / community domain on this topic. Thanks!
- Ted
