High power consumption in deep sleep mode in nRF5340

[Jithin A]

Hi,
I am trying to put the nRF5340 to deep sleep, my application is built with TF-M (_ns).
When tested with the sample system_off application (built without TF-M) I observe 0.25uA.
If I integrate the same into my project, I observe 0.25mA. I assume the device is not entering to deep sleep, am I missing any configuration here? or why I am observing this huge difference?

Below is the prj.conf file used in my project.

CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y
CONFIG_TFM_IPC=y
CONFIG_NRF_SPIM3_SECURE=y
CONFIG_NRF_TWIM2_SECURE=y
CONFIG_NRF_TIMER2_SECURE=y
CONFIG_NRF_PWM0_SECURE=y
CONFIG_NRF_TIMER1_SECURE=y
CONFIG_NRF_PWM1_SECURE=y
CONFIG_NRF_GPIOTE0_SECURE=y
CONFIG_ADC=y
CONFIG_PM=y
CONFIG_PM_DEVICE=y

Below is the code snippet of how I am putting the device to deep sleep in non-secure.

pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

Please guide me through this
Thank you in advance.

[Jithin A]

Hi, 

I have set the breakpoint as mentioned, I see it is not coming to the break point. Do I need to call the API explicitly?

For now, to put the device into sleep mode I am calling the below API.

pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

 

[Vidar Berg]

Hi,

No, you should not have to call the API directly. You do however need to let the program enter the idle thread. For instance, by calling k_sleep() after pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

[Jithin A]

Thanks for the quick response, 

Below is how we have implemented:

pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

/* Now we need to go sleep. This will let the idle thread runs and
 * the pm subsystem will use the forced state. To confirm that the
 * forced state is used.
 */
k_sleep(K_SECONDS(2U));

We have also TF-M (secure) application running along with non-secure.

Is it ok to leave the TF-M application as is or do we need to configure in TF-M to indicate the MCU to go to sleep mode?

[Vidar Berg]

The TF-M should not have any effect on this. You can also build the system_off sample for nrf5340dk_nrf5340_cpuapp_ns to confirm this. 

Would you mind trying to debug the system_off sample to see if the breakpoint gets reached then? 

[Jithin A]

Would you mind trying to debug the system_off sample to see if the breakpoint gets reached then? 

[AJ]--> We confirm it is coming to the breakpoint when we debug system_off sample.

Below are our additional findings:

Example: system_off

• Board: nrf5340dk_nrf5340_cpuapp
• Power consumption at idle: 0.6uA

• Board: nrf5340dk_nrf5340_cpuapp_ns
• Power consumption at idle: 0.6uA

Example: TF-M secure peripheral partition

• Board: nrf5340dk_nrf5340_cpuapp_ns
• Power consumption at idle: 0.21mA
• No changes made to the example except put the device into sleep mode as in system_off example and we observe it is taking very high power in idle state.

We want to know why this huge difference in the power consumption.

NOTE: All the above are tested with nRF5340-dk

[Vidar Berg]

Is it the TF-M secure peripheral partition from SDK v2.3.0? I tried it here on a 5340 DK and I measure around 0.8uA in System OFF:

Changes I made to force it to system OFF:

--- a/src/main.c
+++ b/src/main.c
@@ -7,6 +7,9 @@
 #include <zephyr/kernel.h>
 #include <tfm_veneers.h>
 #include <tfm_ns_interface.h>
+#include <zephyr/pm/pm.h>
+#include <zephyr/pm/device.h>
+#include <zephyr/pm/policy.h>

--- a/prj.conf
+++ b/prj.conf
@@ -6,8 +6,14 @@

 CONFIG_NRF_SPIM3_SECURE=y
 CONFIG_NRF_GPIOTE0_SECURE=y
 CONFIG_TFM_ISOLATION_LEVEL=1
+CONFIG_PM=y
+# Required to disable default behavior of deep sleep on timeout
+CONFIG_PM_DEVICE=y
 
 #include "secure_peripheral_partition.h"
 
@@ -63,4 +66,5 @@ void main(void)
 	k_work_init_delayable(&send_work, send);
 
 	k_work_schedule(&send_work, K_NO_WAIT);
+	pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});
 }
 
 

[Jithin A]

We try programming TF-M secure peripheral partition sample application build with v2.3.0 toolchain and confirm we are getting 0.6uA during deep sleep.

We are working on some changes in our project, let me test and get back to you.

Thank you.