High Current Consumption in nRF5340 in sleep mode

[Jagan K]

Hi all,

We are working on a project that uses the nRF5340 and nRF7002 combo. In our application, the device enters a low-power mode on the nRF5340 during sleep, with the nRF7002 turned off.

We followed the low-power example code, but we're seeing a high current draw of 3 mA on the nRF5340 alone on our custom board. When we tested the same example on the nRF7002 DK and measured the current at P22, we observed only 14 µA.

Our custom board design follows the nRF7002 DK as reference and we've even removed extra pull-ups and pull-downs, but the current remains the same. Interestingly, when we run the example SYSTEM OFF mode code on the same custom board, we observe a current draw of 5 µA by nRF5340, whereas the DK consumes only 1 µA. This difference can be accepted due to some design/parts.

The main difference between the DK and our design is the operating voltage: the DK uses 1.8V, while our custom board uses 3.3V. While some variation due to this voltage difference is expected, a 3 mA difference seems excessive.

• Are there any code changes needed for the 3.3V voltage rail?
• What are the other steps can be taken from our side to reduce the sleep current?

Thanks,

Jagan K

[Håkon Alseth]

Hi,

 

If operating nRF5340+nRF7002 in QSPI mode, 3.3V is not recommended due to erratas #133, #136, #159 here:

https://docs.nordicsemi.com/bundle/errata_nRF5340_Rev1/page/ERR/nRF5340/Rev1/latest/err_340_new.html

 

If you are operating with "normal" SPI, then 3.3V is not problematic.

 

Are there any code changes needed for the 3.3V voltage rail?

No, there should not be, but please note that when you're checking current consumption on the nRF7002-DK, there are separate voltage nets for the nRF7002 and the nRF5340:

https://docs.nordicsemi.com/bundle/ug_nrf7002_dk/page/UG/nrf7002_DK/nRF5340_nRF7002_measure_current.html

 

If you only measure the "VBAT" line going into the nRF7002 IC, then this might explain the differences you're seeing.

 

Q1: Are you operating on SPI or QSPI?

 

We followed the low-power example code

Q2: Which example is this?

 

Kind regards,

Håkon 

[Jagan K]

Hi Hakon,

Thanks for your Support.

1. We are operating in QSPI. But now we are focusing on the Power Management. We worked on 3.3V rail using QSPI, so far no issues faced with nRF7002 and it's been working. We will take account on this voltage rail for QSPI.

2. We followed the example file from below path
C:\ncs\v2.6.1\zephyr\samples\subsys\pm\latency

Regards,

Jagan K

[Jagan K]

Thanks Håkon.

I will check this code and let you know.

While checking the some blogs on the Power optimization and we came across some power states in PMU of zephyr.
Optimizing Power on nRF5340 SoC Designs

In those states, internal RTC is supported or not?

Regards,

Jagan K

[Jagan K]

Hi Håkon,

 Using the ncs/zephyr/samples/basic/blinky and set "CONFIG_SERIAL=n" in the prj.conf, we can able to achieve the low current of 15 uA by nRF5340.

We are now doing some changes as per our application and testing. We will let you know.

Thanks,

Jagan K

[Håkon Alseth]

Hi Jagan K,

 

Jagan K said:

 Using the ncs/zephyr/samples/basic/blinky and set "CONFIG_SERIAL=n" in the prj.conf, we can able to achieve the low current of 15 uA by nRF5340.

We are now doing some changes as per our application and testing. We will let you know.

I am glad to hear. 15 uA sounds a bit high for the nRF alone, but if there are other ICs on your board, this might be close to the base current.

 

Jagan K said:

Optimizing Power on nRF5340 SoC Designs

This guide is a bit old, as we use PM_DEVICE only. You can see a more updated example of this via this thread:

 RE: How to make zephyr power management unit work with NRF52? 

 

Kind regards,

Håkon

[Jagan K]

Hi Håkon,

   15uA is due to a Pull-up connected to nRF5340. After isolating that, we can able to achieve the current of 1.5 - 5 uA in nRF5340.

1. When we increased the samples, we observed that current consumption of nRF5340 varies for one board to board like,
D1 - 2.6 uA
D2- 4.5 uA
D3 - 1 uA

This difference between SOCs are common or not ? And is the above values are acceptable?

2. And we do have a some PULL-UPs connected to nRF5340 for the Interrupt feature. Before entering the Idle state, at what state I need to keep those pins.

Regards,

Jagan K

[Håkon Alseth]

Hi,

 

Jagan K said:

This difference between SOCs are common or not ? And is the above values are acceptable?

The target will be around 4 uA, with all RAM retained.

 

Depending on what multimeter you have used, and its accuracy in the lower uA range, it is expected to see some variance just from the measurement itself. In addition, there will be some chip-to-chip variation between the nRF's.

Jagan K said:

2. And we do have a some PULL-UPs connected to nRF5340 for the Interrupt feature. Before entering the Idle state, at what state I need to keep those pins.

This highly depends on what you need those pins to be.

Do you need a wake-up condition on those pins from external hardware? if so, setup an interrupt on those pins with the appropriate level. See this sample on how to do that:

https://github.com/nrfconnect/sdk-zephyr/blob/main/samples/basic/button/src/main.c#L58

But use a defined level instead of rising/falling edge, as this draws less power in sleep. For instance "GPIO_INT_LEVEL_LOW".

 

Kind regards,

Håkon

[Jagan K]

Thanks Håkon for the clarification.

#2. We are planning to go with System ON Idle mode. In this mode, we need some pins with Interrupt feature to wake-up using external hardware from the Idle mode. These pins are connected to external Pull-ups.

Regards,

Jagan K

[Håkon Alseth]

Hi Jagan K,

 

Jagan K said:

These pins are connected to external Pull-ups.

This means active low, meaning that you should set a interrupt on level low for waking up the nRF:

Håkon Alseth said:

For instance "GPIO_INT_LEVEL_LOW".

 

Kind regards,

Håkon

[Jagan K]

Hi Håkon,

Thanks, I am checking this change now. We will update you.

And while testing the wakeup using the internal counter, we can able to set upto max of 5 mins. Is there any limitation for  the max time? We are following the below example
zephyr/sample/driver/counter/alarm

Regards,

Jagan K

[Håkon Alseth]

Hi Jagan K,

 

That library does not handle the overflow, meaning that in 2^24/32768 - 1  = 511.9 seconds, it cannot set the alarm further than the maximum counter of the RTC peripheral.

 

Kind regards,

Håkon

[Jagan K]

Hi Håkon,

Thank you for your continued support!

Our queries regarding sleep current and RTC are resolved. Now, we are working on fully integrating all components.

Additionally, I would like to confirm if the nRF5340 supports wake-up from a network interrupt triggered by an external device via BLE/Zigbee?

Regards,

Jagan K