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.