High Current Consumption in nRF5340 in sleep mode

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Thu, 28 Nov 2024 04:50:06 GMT

Hi Holman,

We can able to achieve the 5uA current in nRF5340 in 3.3V rail itself with the Blinky code:ncs/zephyr/samples/basic/blinky and set "CONFIG_SERIAL=n" in the prj.conf,

Once if you can achieve with the above example, then you need to do the changes in your application. Check this & let us know.

Thanks,

Jagan K

RE: High Current Consumption in nRF5340 in sleep mode

HolmanB — Wed, 27 Nov 2024 17:57:02 GMT

Hello Jagan K,

I’m very interested in the solution to your issue, as I’m facing a similar problem with the power consumption of the nRF5340. Could you please clarify whether you had to change the nRF5340 power rail from 3.3V to 1.8V to achieve those low power values?

Thank you in advance for your insights!

Holman.

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Fri, 27 Sep 2024 10:39:53 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Fri, 27 Sep 2024 10:37:21 GMT

Håkon,

Any examples to test this application?

Thanks,

Jagan K

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Fri, 27 Sep 2024 10:07:57 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Fri, 27 Sep 2024 09:39:03 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Fri, 27 Sep 2024 08:18:15 GMT

Hi,

[quote user="Jagan K"]

Thank you for your continued support!

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

[/quote]

I am glad hear, and happy to help out!

[quote user="Jagan K"]

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

[/quote]

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

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Fri, 27 Sep 2024 05:44:54 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Mon, 23 Sep 2024 07:24:13 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Fri, 20 Sep 2024 05:44:48 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Thu, 19 Sep 2024 12:46:58 GMT

Hi Jagan K,

[quote user="Jagan K"]These pins are connected to external Pull-ups.[/quote]

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

[quote user="hkn"]For instance "GPIO_INT_LEVEL_LOW".[/quote]

Kind regards,

Håkon

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Thu, 19 Sep 2024 12:43:22 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Thu, 19 Sep 2024 12:05:38 GMT

Hi,

[quote user="Jagan K"]This difference between SOCs are common or not ? And is the above values are acceptable?[/quote]

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.

[quote user="Jagan K"]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.[/quote]

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

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Thu, 19 Sep 2024 11:07:07 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Thu, 19 Sep 2024 10:42:02 GMT

Hi Jagan K,

[quote user="Jagan K"]

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.

[/quote]

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.

[quote user="Jagan K"]Optimizing Power on nRF5340 SoC Designs[/quote]

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

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Thu, 19 Sep 2024 04:33:39 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Wed, 18 Sep 2024 10:25:33 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Wed, 18 Sep 2024 08:53:08 GMT

Hi Jagan K,

[quote user="Jagan K"] And I would like to get some information on the Sleep modes in nRF5340. We are planning to use internal RTC(Real time counter) in nRF5340 to wake device from sleep. For this application, which mode is preferred and how can we achieve that?[/quote]

This will be the system on idle mode, which ideally should give around 3 uA, depending on which state the network core is in:

https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/current_consumption/doc/current_consumption.html#ariaid-title3

However; system on idle is a dynamic mode, meaning that if there is any other peripheral requiring the peripheral clock tree, such as UART, the current consumption will go up to around 650 uA:

https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/current_consumption/doc/current_consumption.html#ariaid-title23

So in this mode, it is important to turn off asynchronous peripherals, such as the UART.

[quote user="Jagan K"] Is there any examples available to check the sleep mode with the internal RTC?[/quote]

All examples use the RTC, as it is required by the zephyr kernel.

To get a low power consumption, I would recommend that you check out the ncs/zephyr/samples/basic/blinky and set "CONFIG_SERIAL=n" in the prj.conf.

Kind regards,

Håkon

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Wed, 18 Sep 2024 07:47:04 GMT

Hi Håkon

Thanks for the support. We will check from our side and let you know.

And I would like to get some information on the Sleep modes in nRF5340. We are planning to use internal RTC(Real time counter) in nRF5340 to wake device from sleep. For this application, which mode is preferred and how can we achieve that?
Is there any examples available to check the sleep mode with the internal RTC?

Regards,

Jagan K

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Tue, 17 Sep 2024 13:52:06 GMT

Hi,

Thank you so much for elaborating, this is very helpful.

Given that there is no issue with current in SYSTEMOFF state, it indicates that the current is coming from the nRF5340 host controller side.

3 mA sounds a bit high for it to only be QSPI:

https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/current_consumption/doc/current_consumption.html#ariaid-title13

As it will use approx. 1.8 mA when idle, but it is worth exploring this anyway.

Could you check that "CONFIG_NRF700X_QSPI_LOW_POWER=y" is set on your side?

If this is not set, the QSPI interface will always be left on after transactions.

Kind regards,

Håkon

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Tue, 17 Sep 2024 12:44:17 GMT

Hi Hakon,

#1. In 3.3V rail, nrf7002 worked under QSPI, so we haven't done any change, but we are discussing & planning for the 1.8V power rail change.

#2. In system OFF case, there is no issue with the current consumption and we have verified that.
But when we try to put the device in low power mode, the current consumption is high that nrf5340 chip alone takes 3.2mA. In this state, power supply for nRf7002 is turned OFF.

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Tue, 17 Sep 2024 12:03:47 GMT

Hi,

[quote user="Jagan K"]We worked on 3.3V rail using QSPI, so far no issues faced with nRF7002 and it's been working[/quote]

I would strongly recommend that you read the erratas mentioned here carefully:

[quote user="hkn"]

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

[/quote]

There are quite a few side-effects of running 3.3V QSPI operation.

[quote user="Jagan K"]2. We followed the example file from below path
C:\ncs\v2.6.1\zephyr\samples\subsys\pm\latency[/quote]

Have you verified that the nRF5340 is indeed in system off mode? If it still draws 3 mA, then it indicates that there is an issue with for instance a GPIO state or similar.

Can you explain which mode the device is in when you're seeing 3 mA? And how do you handle the nRF7002 in that state?

Kind regards,

Håkon

RE: High Current Consumption in nRF5340 in sleep mode

Jagan K — Mon, 16 Sep 2024 13:31:48 GMT

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

RE: High Current Consumption in nRF5340 in sleep mode

Håkon Alseth — Mon, 16 Sep 2024 12:02:18 GMT

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.

[quote user=""]Are there any code changes needed for the 3.3V voltage rail?[/quote]

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?

[quote user=""]We followed the low-power example code[/quote]

Q2: Which example is this?

Kind regards,

Håkon