The first thing we should do before starting with current measurements is to verify our setup. In this exercise we will use the system OFF mode to check if we have any leakage current in our setup, and check if we are able to achieve the sub 1 uA specified in the datasheet.

To ensure that the firmware we run is actually entering System OFF, we will use pre-compiled hex files.

We will also learn how we can compile our own System OFF firmware.

Exercise steps

1. Measurement setup

1.1 Connect the measuring equipment to the DK.

First we want to connect our measuring equipment to the DK, in our case the Power Profiler Kit II (PPK2) in source meter mode. Using source meter mode is always the best option, so if you have equipment that can output voltage and measure current at the same time (SMU), you should go for this option.

It is important that the USB cable to the DK is connected. The DK is not designed to work without the USB cable connected, and you will get leakage current.

Using this setup, we can program new firmware to our device without reconnecting any wires. Just make sure that the power output is turned on, on the SMU. And then you would typically power cycle the device after flashing, using the SMU software.

• nRF54L15 DK
• nRF54LM20 DK
• nRF54LS05 DK
• nRF54LV10 DK

Remove the jumper on P6 (VDD CURRENT MEASURE), connect VOUT on the PPK2 to nRF54 on the P6 header (red cable in the image below) and GND to GND on the P6 header (black cable in the image below)

Remove the jumper on P14 (VDD nRF CURRENT MEASURE), connect VOUT on the PPK2 to the middle pin on the P14 header (red cable in the image below) and GND to GND on the P14 header (black cable in the image below).

Remove the jumper on P6 (VDD CURRENT MEASURE), connect VOUT on the PPK2 to nRF54 on the P6 header (red cable in the image below) and GND to GND on the P6 header (black cable in the image below)

Remove the jumper on P6 (VDD CURRENT MEASURE), connect VOUT on the PPK2 to nRF54 on the P6 header (red cable in the image below) and GND to GND on the P6 header (black cable in the image below)

Important

Warning!

The nRF54LV10 SoC can support a voltage range of 1.2 to 1.7. Make sure you do not go above the max operating voltage, as this may damage the chip.

1.2 Open nRF Connect for Desktop and launch the Power Profiler application.

1.3 Select the PPK2 in the drop-down menu under Select Device.

Make sure your PPK2 is connected to your computer via a micro-USB cable and turned on.

Use the USB DATA/POWER line to power the device.

1.4 Select source meter mode, set the supply voltage to 3000 mV, and enable power output(The LED on the PPK2 should be red, indicating it’s in source mode).

We typically want to set the supply voltage to 3V, as this matches the datasheet numbers. But you can choose another voltage within the operating range for the chip.

If you choose to use ampere meter mode, note that the default voltage on the DK is 1.8V. So these measurements will not match your 3V source meter mode measurements.

It is important to click “enable power output” before flashing firmware to the DK, and starting the measurements. You can toggle this switch after programming in order to do a power cycle. Also if you want to restart your test, this is a convenient way of power cycling the chip.

2. Flash firmware to the DK.

First we will start by programming a pre-compiled hex file, so that we are sure that there is nothing wrong with the firmware.

If you are doing this on a custom board, you might get increased current consumption when running this hex, because external components are not initialized correctly. If that is the case, you can look at the code provided in step 4, and compile your own firmware, with the necessary devicetree/GPIO configurations.

• nRF54L15 DK
• nRF54LM20 DK
• nRF54LS05 DK
• nRF54LV10 DK

Download the hex file available in the course GitHub repository

Download the hex file available in the course GitHub repository

Download the hex file available in the course GitHub repository

Download the hex file available in the course GitHub repository

You can program the hex using the nrfutil command line tool (CLI):

nrfutil device program --firmware <hexfile>

Or you can use the Programmer app:

2.0 Open nRF Connect for Desktop, and launch the Programmer desktop application.

2.1 From the Select Device menu, choose your nRF54L DK (nRF54L15 DK, nRF54LM20 DK, nRF54LS05 DK, nRF54LV10A DK), then click on Add file. Select the binary file downloaded in the step 1.2.

2.2 Click Erase & write.

Programmer app available through nRF Connect for Desktop

2.3 Examine the log. On a successful write, you should see a log similar to the following:

 INFO Writing HEX to Application core
 INFO Writing HEX to Application core 0%
 INFO Writing HEX to Application core 50%
 INFO Writing HEX to Application core 50%
 INFO Writing HEX to Application core 63%
 INFO Writing HEX to Application core 75%
 INFO Writing HEX to Application core 88%
 INFO Writing HEX to Application core 100%
 INFO Writing HEX to Application core completed
 INFO Reading memory for Application core
 INFO Reading memory for Application core 0%
 INFO Reading memory for Application core 100%
 INFO Reading memory for Application core completed
 INFO Parse memory regions for Application core
 DEBUG Sending event "programmer: running nrfutil device"
 DEBUG Sending event "programmer: running nrfutil device"
 DEBUG Sending event "programmer: running nrfutil device"
 INFO Reading readback protection status for Application core
 INFO Reading readback protection status for Application core 0%
 INFO Reading readback protection status for Application core 100%

Close the Programmer app.

Always do a power cycle after programming to be sure that the device is no longer in debug mode.

3. Measure System OFF.

Start the measurement and observe the average current over a longer time period. > 10 seconds.

Here is a measurement conducted on the nRF54L15 DK, using the Power Profiler Kit:

Verify that the average current over a longer period matches the datasheet number:

If we want to investigate the current profile in more details we can first try to recognize the refresh spikes. In System OFF mode we would expect a spike period of 100 to 200 ms, according to what we discussed in the Measurement setup validation and error mitigation section.

Here is a plot selecting the area which covers two refresh spike periods:

The current is consumed in periodic bursts, meaning that we need to treat this as a periodic signal. The distance between the cursors should be a multiple of the periodic signal, as shown in the plot above, as discussed in the periodic signal and extrapolating data section.

Observe that the average current including only a few refresh spikes is the same as the average current over a longer time period, if we place the cursors correctly.

Also observe that the floor current between the spikes is 0.5 uA. This is the lowest we can have, as some current is also consumed by the chip itself directly on VDD. If we had leakage current on VDD from external components or through GPIOs, this floor current would have been increased, while keeping the same refresh spike distance. We will investigate this scenario in step 4.

So what information have we extracted from our measurements so far?

1. We have a periodic signal with a period of about 100ms → Indicating we are in System OFF
2. We have very low leakage on VDD → Floor current is < 0.5uA. Our measurement setup is good.
3. The average current is 0.7 uA → Matching the datasheet system OFF current

4. Compile your own code

Below is a code snippet that can be used if you want to compile your own System OFF sample. This is useful if you are using a custom board with it’s own devicetree. The devicetree will set the GPIO configuration, and it will be retained in System OFF.

The easiest way to create your own System OFF firmware is to start with the zephyr/samples/hello_world sample, compile it, and make sure that it runs and prints to the console. Then we will add the code below.

Alternatively, in the GitHub repository for this course, go to the base code for this exercise, found in l3/l3_e1.

4.1 Turn off the UART logger module and enable support for System power off.

First we want to turn off the UART logger module by adding CONFIG_SERIAL=n in the prj.conf file. While System OFF will turn off the UART as well, it will not reconfigure the GPIOs. During System OFF mode, the GPIO pins will retain their configured state. So if we do not turn off the UART through CONFIG_SERIAL=n, we will get some leakage through the GPIOs.

We also want to enable support for System power off, through enabling CONFIG_POWEROFF.

Add the following lines to the prj.conf file

CONFIG_SERIAL=n         # Do not initialize UART logger module
CONFIG_POWEROFF=y       # System OFF library

CONFIG_SERIAL=n         # Do not initialize UART logger module
CONFIG_POWEROFF=y       # System OFF library

4.2 Turn off the low frequency clock, RAM sections for CRACKEN and ICACHE and enter System OFF.

Then, in main.c, we want to turn off the low frequency clock and the GRTC through the sys_clock_disable() call, otherwise these will run in System OFF and consume around 0.2 uA. This is only relevant for the nRF54 series, as the previous series (nRF52/53) did not support RTC and LF clock in System OFF.

An additional NRF_MEMCONF->POWER[1].RET &= ~0xE is added, as we can turn off RAM sections 33, 34 and 35 as well, since we do not need these for our experiment. These sections are not covered by the sys_poweroff() call, and need to be switched off manually. This will reduce our current with another 0.3 uA.

Please refer to table 1 in the following link for more information on these RAM sections: Technical Documentation. Memory retention is covered in depth in lesson 5.

Replace the contents of main.c with the following code snippet

#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/sys/poweroff.h>
#include <zephyr/drivers/timer/system_timer.h>

int main(void)
{
    //Turn off GRTC and LF clock:
	sys_clock_disable();

    //Turn off RAM sections for CRACKEN and ICACHE:
	NRF_MEMCONF->POWER[1].RET &= ~0xE;

    /* STEP 5 - Increase VDD leakage */

    //Enter System OFF:
	sys_poweroff();

	return 0;
}

#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/sys/poweroff.h>
#include <zephyr/drivers/timer/system_timer.h>

int main(void)
{
    //Turn off GRTC and LF clock:
	sys_clock_disable();

    //Turn off RAM sections for CRACKEN and ICACHE:
	NRF_MEMCONF->POWER[1].RET &= ~0xE;

    /* STEP 5 - Increase VDD leakage */

    //Enter System OFF:
	sys_poweroff();

	return 0;
}

4.3 Build and flash the sample to your DK.

Verify that you have the same current consumption as with the pre-compiled hex.

5. Increase and investigate VDD leakage.

If we want to investigate this scenario of having a leakage on VDD, and correlate this with our measurements, we can add the following code to our main() function, right above the sys_poweroff() call:

NRF_P0->PIN_CNF[4] = 0xD;  // Set P0.04 as output with a pullup to VDD
NRF_P0->OUTCLR = 1<<4;     // Set P0.04 output to low (GND)

NRF_P0->PIN_CNF[4] = 0xD;  // Set P0.04 as output with a pullup to VDD
NRF_P0->OUTCLR = 1<<4;     // Set P0.04 output to low (GND)

What this does is set the pin a low output. But we also configure a pullup to VDD. This means that current will flow directly from VDD through the pullup, down to GND.

This is usually not a valid configuration for an application, but we will use this configuration just for the purpose of showing an increased VDD current.

The internal pullup resistor on each GPIO is specified to be between 12 kOhm and 16 kOhm. In this example we set VDD to 3V, so we would expect a current of 188 uA to 250 uA flowing directly on the VDD domain.

Here is a plot showing how the VDD floor current has increased to 190 uA, but the refresh spike period stays at the same 100ms, as in our previous measurements, meaning that we are still in System OFF, but are having a 190 uA leakage on VDD

6. Measure System ON IDLE.

Remove the sys_clock_disable(), pin configuration and sys_poweroff() from main.c, and observe that we are now in System ON IDLE.

Remove or comment out the contents of main() so it looks like this

int main(void)
{
	return 0;
}

int main(void)
{
	return 0;
}

Running this over a longer time period, we get an average current of ~2.45 uA

The expected current consumption running on nRF54L15 can be found in the datasheet under this scenario:

This is the default idle configuration in Zephyr, since we now have GRTC running from LFXO as our system timer, and the default full RAM retention.

Note that the RAM retention current is varying from device to device, and the the datasheet lists the typical value, as we discussed in this section. In this context it means that in reality the value has a normal distribution and that the typical value is the mean value across all devices. So if your measurement doesn’t match 100%, this is the reason. And that is also why we wanted to confirm our measurement setup with System OFF first.

We should further investigate the current profile, confirming that the refresh spike period is now much shorter than our System OFF measurements, due to the internal current draw is now much higher.

Here we have a spike period of around 10 ms, which fits with System ON IDLE measurements as we discussed Measurement setup validation and error mitigation topic

System ON IDLE is further investigated part of Lesson 5 – Exercise 3 – Measuring the impact of RAM retention settings

Now that we have confirmed that our measurement setup is correct, and we the correct idle current We will continue onto the next lesson where we add Bluetooth advertising to our application.