Zephyr 3.5: Power Management subsystem

[bojan]

Hello, guys. 

We have the application running on Zephyr RTOS (nRF52840 SoC) that is periodically switching between the sleeping (System ON) and active modes of operation. In System ON mode of operation the sample was consuming a few uA of current (as expected).

We have recently migrated from Zephyr v3.3.0 to the latest one (v3.5.0). When checking the current consumption profile of our application in new Zephyr v3.5.0 environment, we noticed some strange periodic (~2.5ms period) current consumption spikes that are significantly increasing the average current consumption:

Here are the power management related flags that we have in our application:

CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y

Do you have any idea what might be the cause of the current spikes in new Zephyr v3.5. environment?

Is there any additional power management related flag that we should activate? 

Thanks in advance for your time and efforts!

Sincerely,
Bojan.

[Einar Thorsrud]

Hi Bojan,

I am not able to say much based on this. Can you elaborate on what you are doing so that we can understand more about what would cause this?

Please also note that while I don't have any reason to believe this is related, Nordic only support the nRF Connect SDK, and not vanilla Zephyr.

[bojan]

Hello, Einar Thorsrud 

Sorry for a delayed reply. 

Let me update the status of our issue. We ported and tested our sample application in NCS environment. In NCS 2.4.2 that embeds Zephyr v3.3.99, the sample behaves as expected, no current spikes:

The same sample application in latest NCS 2.5.0 environment that embeds Zephyr v3.4.99 does not behave as expected. The above mentioned periodic current spikes started to appear:

We tried to figure out what might be the reason for that and it seems that the current spikes are there because the UART console is not properly turned OFF with:

pm_device_action_run(console, PM_DEVICE_ACTION_SUSPEND);

It seems that the above power management API did not have effect (even though we set the CONFIG_PM item to y in our prj.conf file) because CONFIG_HAS_PM flag was not set to y. According to the Zephyr migration guide, this needs to be done:

Platforms that implement power management hooks must explicitly select CONFIG_HAS_PM in Kconfig.

When we explicitly set HAS_PM in our Kconfig file with:

config APP_PROVIDE_PM_HOOKS
	bool "Application provides PM hooks"
	default y
	select HAS_PM

the current spikes disappeared.

If the nRF52840 platform supports the power management hooks, would it make sense that you include that info directly in the config SOC_SERIES_NRF52X definition (zephyr/boards/soc/arm/nordic_nrf/nrf52/Kconfig.series file):

config SOC_SERIES_NRF52X
	bool "Nordic Semiconductor nRF52 series MCU"
	select ARM
	select SOC_COMPATIBLE_NRF52X
	select CPU_CORTEX_M4
	select CPU_HAS_ARM_MPU
	select SOC_FAMILY_NRF
	select XIP
	select HAS_NRFX
	select HAS_NORDIC_DRIVERS
	select HAS_SEGGER_RTT if ZEPHYR_SEGGER_MODULE
	select HAS_SWO
	select HAS_POWEROFF
	select HAS_PM
	help
	  Enable support for NRF52 MCU series

 

Sincerely,
Bojan

[Einar Thorsrud]

Hi Bojan,

Thank you for the detailed explanation. HAS_PM was added for also nRF platforms originally, but then removed here, as there should not be any need for it. See the commit message for details. This system is a bit messy, but the PM and DEVICE_PM systems should be independent. So pm_device_action_run() does not depend on CONFIG_HAS_PM.

Do you have some code that use the PM hooks (and therefore fails without CONFIG_HAS_PM)?