nRF5340 power management

[Yanpengwu]

Hi Support team,

We plan to develop an IoT device with nRF5340 and the power consumption management is a key feature for us. I just verified some functionalities with nRF5340 DK.
Our requeirements are:
(1) The network core only wakes up once a week to report data (most time it is in Force-OFF mode). When it sleeps, all of its peripherals will be in low-energy mode.
(2) Application core works in the RUN state of System-on mode collects data from sensors per minute, and then goes into IDLE state. When it goes into IDLE, all of its peripherals will be in low-energy mode.

My questions are:
1. For the power management of peripherals, which peripherals of the application core and network core can be controlled separately?
2. Should I use API pm_device_action_run() in \external\zephyr\subsys\pm\device.c to conntrol peripherals power mode?
3. Could you provide a sample to force/release the network core to Force-OFF mode?
4. Is it possible to control the peripherals of both application and network cores from the application core?

Thank you very much!

Best regards,
Yanpeng Wu

[Einar Thorsrud]

Hi,

1. For the power management of peripherals, which peripherals of the application core and network core can be controlled separately?

All peripherals can be controlled separately, though they use some of the same resources (like clocks and regulators). In a low power application you typically suspend peripherals whenever they are not in use.

2. Should I use API pm_device_action_run() in \external\zephyr\subsys\pm\device.c to conntrol peripherals power mode?

Yes. Peripherals that are handled by the stack like the Radio, or the TIMER used by the stack, etc will be automatically handled. But other peripherals that you use (say UART, TWI or similar), you will have to suspend when no longer needed and resume when needed again i order to reduce power usage.

3. Could you provide a sample to force/release the network core to Force-OFF mode?

Is force off a real requirement (if so why?) or is it enough for it to be in system on sleep mode? The latter is the approach used by our SDK, and that will also result in a very low sleep current (essentially the net core can sleep for the entire time when Bluetooth or other network protocols are not needed). You can refer to the implementation of nrf_reset_network_force_off() to see how to force the network core off (the first register write, the later part release it again). But there are no examples of it being kept off, and it will cause inter process communication to get out of sync. (You can refer to theIPC Service - icmsg sample for a lower-level example which demonstrates resetting the network core and continuing IPC communication).

[Yanpengwu]

Hi Einar,

Thank you for the detailed reply.
In our application, the network core only wakes up once a week to read data from flash memory and report it with LTE. In our initial idea maybe the Force-OFF is a solution, but as you mentioned the IPC will be out of sync after the Force-OFF also needs to be considered, thanks for reminding of this.

As you mentioned, the typical approach used by NCS is to let the network-core in sleep mode. Is there a sample for this? I want to try to set the network core in sleep mode and wake it from applicaiton-core side. Thank you very much.

[Einar Thorsrud]

Are you going to use BLE or any of the other short range protocols that are supported by us on the nRF53? If so, that typically has a part running on the network core and a part on the app core, and you would in practice have to keep the network core out of force off and use it as is intended. If you only use the network core for your specific stuff, then that is not relevant.

For examples of using the network core in sleep mode, you can refer to any of the examples that use both the app core and net core, so for instance any Bluetooth sample built for the net core. The details happens under the hood though, but what happens is that the net core (just as the app core) enters system ON sleep mode in the idle thread, whenever nothing is happening, and it is woken up by an interrupt when needed. If nothing else is happening on the net core, it will sleep until woken up by an IPC interrupt, triggered by the app core.

If you only need the net core for your specific use case, then you can refer to the IPC Service - icmsg sample that I linked to in my previous post. While that release the net core immediately, you can use it as an example of how to communicate and continue to communicate after a net core reset (force off followed by force off release). In principle, you would just have to replace the nrf_reset_network_force_off() call with a separate call to force the net core off, and another call to release it.

[Yanpengwu]

Hi Einar,

Thanks for the reply. We will not use these short-range protocols on nRF53. In our application, the application on two cores is separated (unlike BLE distributes the Host and controller on two cores).

We use application core to collect time series data and store it on the external flash per minute, then use network core to report the data to a third party per week. Because the network core only needs awake per week, so we prefer to force-OFF it. In this sense, the feasible and best solution is to use nrf_reset_network_force_off() to hold/release the network core, right? For the out-of-sync after force-OFF we discussed previously, does it only need to be considered in the application of short-range protocols? In our application, we only need to consider the synchronization of external Flash access, no need for the strict sync as BLE? Thank you very much.

[Einar Thorsrud]

Hi,

Thank you for explaining you application. In this case it seems sensible, and you can use the IPC sample as a reference with the changes discussed earlier. I do not see any issues with that approach in this case.

[Yanpengwu]

Hi Einar,

Thanks for your reply, I referred to the IPC sample and can use nrf_reset_network_force_off() to set the network core successfully. In our design, the network core will only use a simple power management(PM) method that sets hold/release of force-off at the right time. However, on the application core a complete PM strategy is needed to optimize the power consumption.

I went through the documentation of PM and found:
1. In Zephyr, there are two levels of PM:
        • System PM (zephyr/soc/arm/nordic_nrf/nrf53/power.c, only support PM_STATE_SOFT_OFF)
        • Device PM (in drivers, UART/SPI/I2C support device power management)
2. In NCS, there is a Power-manager module in CAF.

My questions are:
(1) In CAF Power-manager module, a new set of power states are defined (IDLE, SUSPENDED, OFF, ERROR), but Zephyr system PM defines another set of states (PM_STATE_ACTIVE, PM_STATE_RUNTIME_IDLE, PM_STATE_SUSPEND_TO_IDLE, PM_STATE_STANDBY, PM_STATE_SUSPEND_TO_RAM, PM_STATE_SUSPEND_TO_DISK, PM_STATE_SOFT_OFF). Is the CAF Power-manager module states a simplification or overwrite of the Zephyr system PM states? What's the relationship of these two sets of states?
(2) In Zephyr device PM, I can use API pm_device_action_run() to suspend/resume a UART/SPI/I2C peripherals manually. In a complete PM strategy, should I use both the CAF Power-manager module and the API pm_device_action_run()? When an event, fx. wake_up_event or power_down_event was submitted by Power-manager module, the pm_device_action_run() will be called to operate peripherals?
(3) Is there a complete sample for nRF5340 power management?

Thank you very much.

[Einar Thorsrud]

Hi,

1. CAF is a framwork that is used by the Applications under nrf, and may or may not be usefull also for other applications. It does not replace Zephyr functionality (including power management), but is rather at a somewhat different layer. The CAF power management is more on the device level. Depending on your application, it could be better and simpler to avoid using CAF as you need to have a high-level approach that fit your specific product.

2. In the complete PM strategy, you need to ensure that peripherals and other resources are in idle/low power mode or disabled when ever not needed. This is highly application dependent, and I recommend that you manage this yourself (utilizing the Zephyr power management API's).

3. The nRF Desktop reference design is power optimized using CAF (and is what this module was designed for). For using the power management API's you can find different examples, often by searching in the code for "pm_device_action_run".

A key point here is that the Zephyr power management API is quite powerful even though it is simpe. For instance, you can configure pin states for active and sleep states in the Device tree like in this example:

	uart1_default: uart1_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 2, 4)>,
				<NRF_PSEL(UART_RTS, 2, 0)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 2, 5)>,
				<NRF_PSEL(UART_CTS, 2, 6)>;
			bias-pull-up;
		};
	};

	uart1_sleep: uart1_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 2, 4)>,
				<NRF_PSEL(UART_RX, 2, 5)>,
				<NRF_PSEL(UART_RTS, 2, 0)>,
				<NRF_PSEL(UART_CTS, 2, 6)>;
			low-power-enable;
		};
	};

So when pm_device_action_run() is called with PM_DEVICE_ACTION_SUSPEND, not only is the UART peripheral stopped, but the pins are also re-configured (as disconnected inputs with no pull in this case, to minimize leakage). And when you call pm_device_action_run() with PM_DEVICE_ACTION_RESUME, the pins are reconfigured and UART re-enabled).