Power Consumption of nRF5340

[Michael Nemanov]

Hi,

I'm evaluating the new nRF5340-PDK and trying to put the device in low power mode. My steps so far:

1. Cut SB40 to allow measuring current via P22.
2. Connect power measurement equipment to P22.
3. Build an example application from the SDK with the command

   west build -b nrf5340_dk_nrf5340_cpuapp

4. Program the binary via the command

   nrfjprog -f NRF53 --eraseall
   nrfjprog -f NRF53 --program <example path>\build\zypher\\zephyr.hex

5. Reset the board via SW5.

The examples are built and programmed successfully (I can see the expected prints on UART).
However, I do not see any significant current changes when the applications are active or idle. My highest measurement is 3.40mA while the lowest is 3.28 mA.
I've tried using the zephyr\samples\subsys\power\device_pm and nrf\samples\nfc\record_text samples, both with the same results.

Am I missing some configuration during the build phase? Should I add some code to put the system into low power mode explicitly? I would have expected it to happen implicitly by the kernel once there are no active tasks.

Thanks,
Michael.

[Håkon Alseth]

Hi Michael,

 

This line:

https://github.com/NordicPlayground/fw-nrfconnect-zephyr/blob/master/boards/arm/nrf5340_dk_nrf5340/nrf5340_cpunet_reset.c#L55

Will release the network CPU, and if there's no program in the network core, it'll just run, causing a higher power consumption.

You can either put the core back to sleep, or compile a simple program that goes straight to wfe (or k_cpu_idle() when using the rtos API).

If you go to ncs/zephyr/samples/basic/blinky/ and modify the main.c to hold only "while(1) k_cpu_idle();" and build/flash for the network core:

west build -b nrf5340_dk_nrf5340_cpuapp

 

Could you try this and see if the current goes down?

Note that since you have UART output, you should see approx. 0.5 mA current consumption due to the UART RX being active. if you disable serial (CONFIG_SERIAL=n), it should go lower.

 

Kind regards,

Håkon

[Michael Nemanov]

Michael Nemanov said:

NRF_RESET->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Hold;

OK, this drops the current from the above mentioned 3.28mA to 2.22 mA. Is this expected? (I saw no data sheet  to reference against).

[Michael Nemanov]

Thanks!

Setting CONFIG_SERIAL=n reduces current to 15 uA when idle. 
Is there any way to keep the serial and the low current (when the UART is not transmitting / receiving)?

Regards,
Michael. 

[Håkon Alseth]

Glad to hear that the current is down!

Michael Nemanov said:

Setting CONFIG_SERIAL=n reduces current to 15 uA when idle. 
Is there any way to keep the serial and the low current (when the UART is not transmitting / receiving)?

 Its the receiver part that is causing the added current. You can theoretically stop the UARTE RX, and later on enable it:

NRF_UARTE0->TASKS_STOPRX = 1;

 

Kind regards,

Håkon

[Michael Nemanov]

"NRF_UARTE0->TASKS_STOPRX = 1;" Indeed lowers the sleep current but only to 180 uA, not the 15uA if the UART is disabled in proj.conf.
Anyway its good enough for me at the moment

Thanks for all the help Håkon.

Regards,
Michael.

[Adrian Eggenberger]

I had some issues with the nRF5340 current consumption today. In fact I'm not able to get a lower current than a 3mA. May I ask you a few questions?
- What version of the nRF Connect SDK did you use?
- How did you measure the current?
- What which example did you finally manage it?
- What version of the nRF5340 PDK did you use?

[Michael Nemanov]

Hi Adrian,

I'm not 100% sure how to determine the PDK/SDK version but the git branch I've started from is v2.1.99-ncs1.

As mentioned above, the current was measured using jumper P22.

I've used the general Zephyr PM example (ncs/zephyr/samples/subsys/power/device_pm).

In that example I had to:
1. Disable the network core.
2. Disable the UART completely (CONFIG_SERIAL=n in prj.conf) or at least disable the Rx task (NRF_UARTE0->TASKS_STOPRX = 1; somewhere in the source code).

Regards,
Michael.

[Adrian Eggenberger]

Hi Michael

With your tipp I was able to reproduce the behavior from you and got the same 15uA. Is the 15uA an explainable value? From the datasheet I would expect a deeper value, right? Maybe a limitation of the development board or the engeneering A chip?

Regards Adrian

[Michael Nemanov]

Good question. Maybe one of Nordic's engineers can help.

Regards,
Michael.