nRF5340-DK Low Power Modes

[Portilha]

Hello everyone,

I'm working with the nRF5340-DK, aiming to achieve the lowest possible power consumption. From what I have read in some posts, I understand that this board should be able to reach consumption levels around 3 to 5 mA. In my setup, I'm using an SMU to power the board (through the P22 connector) and measure current. I've also set the nRF-only mode using the onboard switch to minimize MCU interface consumption. However, my current consumption is around 20 mA, which seems quite high for a chip described as ultra-low-power in the datasheet.

In my proj.conf I have disabled logging to reduce consumption:

CONFIG_LOG=n

CONFIG_SERIAL=n

And in my device tree overlay I have disabled some unused peripherals:

&adc {

status = "disabled";

};

&pwm0 {

status = "disabled";

};

&qspi {

status = "disabled";

};

&uart2 {

status = "disabled";

};

If helpful, I can provide current consumption graphs from the SMU software.

I'm wondering if there are additional configurations or APIs that would allow the board to enter a deep sleep mode, waking periodically to further reduce power consumption. I’ve noticed that Zephyr has APIs for managing low-power modes, but I’m unable to enable CONFIG_HAS_PM in proj.conf, which seems necessary for these functions.

Any advice on this would be greatly appreciated. Thank you!

[Einar Thorsrud]

Hi,

Are we talking about idle current consumption here? If so, I assume you mean uA (micro ampere) where you write mA? If so, 20 uA is a high idle current consumption number, but it is about what I woudl expect if you have a GPIOTE interrupt pin enabled. Could that be the case? If that is the case, you can reduce power consumption by using GPIOTE PORT event as described in this post.

[Portilha]

Hello, yes I was talking about idle current. In the image attached it is possiblle to visualize the current consumption chart. Before any thread or pheripheral initialization I put the system to sleep for 5 seconds (using k_msleep function) and the idle current is about 8.8mA. Then a thread starts running, for another 5 seconds, where the consumption rises and after that the system goes go sleep for 5 more seconds, where the idle consumption is about 13.5mA.

Is there any way to improve this? I really don´t get how to achieve such low currents in the order of micro amps (uA) as you are saying.

[Einar Thorsrud]

Hi,

These are extremely high numbers for idle and I suspect there is either somethign else on your board drawing power (or a measurement issue), so we need to get an overview first.

1. Can you share details about your hardware (scematics, layout and description)? You can do so in a private ticket and refer to this if you do not want to share it in a public thread.
2. Can you show and explain how you are mesuring the current consumption?

[Portilha]

Hello,

As mentioned, I am using the nRF5340-DK development kit, so all hardware information (such as schematics and technical details) is available in the board documentation on Nordic's website. In addition, I have connected an NFC shield and a CAN module to the setup.

For measuring current, I am using an SMU to simultaneously power the board and measure the current draw. Since the NFC shield requires a 5V input, I am connecting the SMU to the Li-Po terminals. I've configured SW9 to the Li-Po position, set SW6 to nRF mode only (to reduce MCU interface power consumption), and left SW10 in the OFF position.

Today, I ran the same test with both the NFC and CAN modules disconnected to see if there would be any difference. Here are the results: the current draw was approximately 3 mA before system initialization and around 9 mA when threads were running.

[Einar Thorsrud]

Do you have a measurement when the device is in idle/sleep and with UART logging disabled? Also, and important: can you share details how you rea measuring? And to get a good reference, can you make a measurement with all external components connected where you test the nRF5x System Off demo and share the current consumption pattern here?

[Portilha]

Hello, sorry for the late response.

The in the previous images that I sent the system should be in idle for the first seconds as I invoke the k_msleep function in the main function:

int main(void)

{

// Set main clock at the correct frequency

(void)SetInternalClock128();

// Initialize services and hardware modules

k_msleep(5000);

...

}

Additionaly, in my proj.conf I have commented out the following options to disable logs:
#CONFIG_LOG=y
#CONFIG_LOG_PRINTK=y

As for the measuring procedure, as I have explained, I am connecting my SMU to the Li-Po terminals and supplying 5V. I have SW9 in the 'Li-Po' position, SW10 in the 'OFF' position and SW6 in the 'nRF only mode', allowing to disconnect the MCU interface, thus reducing power consumption.

I have checked the System Off demo, and for what I have understood it basically initializes an NFC tag and if no activity is detected in the first 3 seconds the system "shuts down", waiting for some activity to be detected to restart. This principle seems interesting and I think it could be applied to my application, however I am using an NFC reader (instead of an NFC tag).

I have performed the tests you have required and I goit the following results: without any external hardware connected I got currents between few micro amps until 500uA (the graph has a lot of noise) which seems a great improvement. With the hardware connected I got around 6mA which seems also acceptable. I am using the ST X-NUCLEO-NFC08A1 reader, if it is useful for you. 

I can open a private ticket, if it easier for you to provide more support. I will leave the results.

 

[Einar Thorsrud]

Hi,

Portilha said:

The in the previous images that I sent the system should be in idle for the first seconds as I invoke the k_msleep function in the main function:

I see. Assuming you have disabled UART that should give you a fre micro amps. And in any case, the nRF itself will never consume 20 mA (except via GPIOs), so I strongly suspect other parts on the board.

Portilha said:

I am connecting my SMU to the Li-Po terminals

I am sorry, I did not spot this before. This should give fairly good results, but the simplest way to measure current on the DK without and get accurate results is to cut SB40 and measure (not supply) via the current measurement header (see Current measurement).

Portilha said:

I have checked the System Off demo, and for what I have understood it basically initializes an NFC

There are two system OFF demos. The one I had on my mind is the one under zephyr/samples/boards/nrf/system_off/. This is generic and does not use the NFC tag peripheral.

Portilha said:

without any external hardware connected I got currents between few micro amps until 500uA (the graph has a lot of noise) which seems a great improvement.

This is more in line with what I would epxect and it points to the additional current draw coming from the external cuircuitry (which as mentionne dbefore it ahs to be, becasue it is difficult to get the nRF to consume 20 mA unless you are really trying).

Portilha said:

I am using the ST X-NUCLEO-NFC08A1 reader,

Looking at it's datasheet I see that it can consume a significant amount of current so depending on which mode it is configure din I would look at this first. Which mode is it in right after the nRF is reset? Is it in one of the modes that consume a lot of current?

Portilha said:

I can open a private ticket, if it easier for you to provide more support. I will leave the results.

Yes, you cna do that. Note that you will need to contact ST regardign power optimization of the NFC reader you are using (which I suspect is where you can gain the most).

[Portilha]

Hello, I will open a private ticket in order to get more information about low power modes. The system off is not suitable for our application, as this mode resets the CPU every time there is a wake up trigger.

[Einar Thorsrud]

Hi,

There is no need for a private ticket for that, this is all public informaiton. The system off example was ment as a simple test to measure current consumption without focusing on your applicaiton. But it seems this is caused by your NFC reader (and the numrbers look sensible refering to it's datasheet), and I expect you need to put this into a low power state. The manufacturer of that should be able to provide more advice on that.