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

[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

[Håkon Alseth]

Hi,

 

Jagan K said:

Thank you for your continued support!

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

I am glad hear, and happy to help out!

Jagan K said:

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

Wake-on-RF is a bit of a strange scenario, as it will involve some sort of duty cycling of the radio itself, and it is usually a term for proprietary protocols.

Bluetooth has in-built timing for the protocol itself, so it is from a RADIO perspective already optimized, especially when running as peripheral. It is a deterministic protocol, meaning that you follow the central and communicate within your provided timing slots.

unfortunately I'm not a zigbee expert, but it is also a protocol implementation, which again has several different modes that you can use:

https://docs.nordicsemi.com/bundle/ncs-2.7.99-cs2/page/nrf/protocols/zigbee/supported_features.html

 

Kind regards,

Håkon

[Jagan K]

Hi Håkon, 

Thank you. Let’s focus on the BLE part itself.What would be the current consumption in this scenario ?

Suppose, two nRF5340 devices are used—one as a gateway and the other as a sensor.  The sensor will communicate with the gateway via BLE, similar to a smart home application. Are there any example projects available for testing this setup?

Regards,

Jagan K

[Håkon Alseth]

Hi,

 

Please see here for a power calculator for nRF5-series bluetooth devices:

 Online Power Profiler for Bluetooth LE 

 

Although the above will give you a indication on what the current consumption will be, it is an estimate, as it does not take into account other running parts of your application, such as any CPU processing, peripherals and external ICs.

I cannot answer what the current consumption will be, the most efficient way to do this is to setup your application, and afterwards optimize.

 

Kind regards,

Håkon

[Jagan K]

Håkon,

Any examples to test this application?

Thanks,

Jagan K

[Håkon Alseth]

What I usually recommend is to look at the examples available, and choose the one that is closest to what your application needs.

 

Kind regards,

Håkon