nRF54L15-DK suspiciously high sleep current

RE: nRF54L15-DK suspiciously high sleep current

hmolesworth — Tue, 19 Aug 2025 16:22:48 GMT

In addition to Hakon's notes you may be unlucky with aliasing. INA229: "The device allows for selectable ADC conversion times from 50 µs to 4.12 ms". Perhaps the ADC sampling is hitting (synchronous with) the hysteretic mode current peaks which would give a huge increase in reported current. Hysteretic mode is described under a different part but it is basically the same: nwp_034 Note also the hysteretic frequency will be different between nRF52840 and nRF54L15 depending on (amongst other factors) the current driver and net bulk capacitance charged by the current pulses.

RE: nRF54L15-DK suspiciously high sleep current

Håkon Alseth — Tue, 19 Aug 2025 13:43:32 GMT

Hi,

I am not sure how robust your power profiler is towards peaks/spikes/switching in general, and I cannot state anything definite based on the limited information I have related to your measurement hardware, but it could be that this buffering in the VDDIO circuitry is causing unwanted side-effects in your current measurements:

It takes in VDD_NRF as a reference to the VDDIO buffer.

This is the reason why the debugger is also turned off when you remove the jumper on P6.

This has approx. 100 nA added leakage when measuring on the DK.

DK hw files are available here if you'd like to look deeper: https://www.nordicsemi.com/Products/Development-hardware/nRF54L15-DK/Hardware-files?lang=en#infotabs

Kind regards,

Håkon

RE: nRF54L15-DK suspiciously high sleep current

Albun — Fri, 15 Aug 2025 16:01:08 GMT

This is a follow up post.

The problem was indeed in my custom current measuring device (in previous posts I have shown its schematics part).

I have tried to measure current consumption of my nRF54L15DK usual standard multimeter, and it shown about 2.6 uA, while my device still measured 32uA like on the pictures I have shown in previous posts.

So, this definitely solves the problem, and as such, it emerges out that the "suspiciously high current" problem was not present at all, and had I measured current with multimeter from the very beginning, I'd have known that my firmware puts the MCU into valid sleep mode, and it consumes valid amount of energy, as declared in specifications.

But still I'm not totally at ease, since this still keeps me wonder what is wrong with my custom measurement device's schematics. Using it with some of my other projects, as I stated before, have shown valid results. So, my device is also functional. But now I know there are some pitfalls...

To get closer to the problem's solution, I tried measuring my other project's PCB (let's name it PCB_X) in these 3 setups:

1. I measured my PCB_X, powered from the battery. My device measures 1uA sleep current (which is 100% true).

2. I tried to power my PCB_X from nRF54L15DK's P6 connector, pin 3. That is, I have 'borrowed' voltage VDDM (which arrives from nPM1300, VOUT1). In this scenario I was astounded to see measurements have risen to 31uA (!!!)

3. I tried same as #2 but instead of P6.3 (VDDM) I have used VDDIO which is routed to many connectors, like P0, P1, P2. This time I have measured almost normal sleep current (higher than 1uA but much closer to it - for now I don't remember exactly)

So, this concludes:

1. My measurement device is somehow influenced by the VDDM (P6.3) generated voltage.

2. I totally have no idea what can influence my measurement device so it starts measuring those extra 30uA. What I can guess is that my measurement device catches some noise and that is the reason of those weird readings.

I'm skillful enough to have developed this device, firmware and software for it, but as it is clear, my knowledge is limited and in such situation I just cannot understand what/who is the culprit in here.

Any ideas what can influence my measurements? I'd be very grateful for comments which will be able to shed any light on this measurement problem.

RE: nRF54L15-DK suspiciously high sleep current

Albun — Wed, 13 Aug 2025 08:30:36 GMT

[quote]SystemInit does not explicitly enable DCDC[/quote]

Sorry, my original mistype, yes, DCDC is not touched in SystemInit(), switching it on is added in other part of my code, but in my very first post here I just stated misleading info. So, just to keep things clear, here is part of my IAR startup code:

pubweak Reset_Handler
section .text:CODE:REORDER:NOROOT(2)

Reset_Handler
bl SystemInit
bl SystemInitEx
b __iar_program_start

Here SystemInit is direct call to Nordic's sytstem_nrf54l.c, and SystemInitEx is my own extra init function, located in my main.c file:

void SystemInitEx()
{
NRF_ICACHE->ENABLE = CACHE_ENABLE_ENABLE_Enabled;
NRF_REGULATORS->VREGMAIN.DCDCEN = REGULATORS_VREGMAIN_DCDCEN_VAL_Enabled;

NRF_OSCILLATORS->XOSC32M.CONFIG.INTCAP = 0x29;
NRF_OSCILLATORS->XOSC32KI.INTCAP = 0x14;
}

[quote]Here's my test, on v0.9.2 of the nRF54L15-DK. sample: nrf/samples/boards/nordic/system_off[/quote]

Thank you for real life graph. This indeed tells me some the error must be my setup for sure. I will have to dig more here on my side. Conserning firmwares tested - I tested some - as I've mentioned before, I tested on blank IAR project and zephyr system_off from your link, also I tested sample projects in zephyr SDK, like blinky, ble beacon, etc - for all of them I had those 35uA current. Also I will try other multimeters.

RE: nRF54L15-DK suspiciously high sleep current

Håkon Alseth — Wed, 13 Aug 2025 07:10:53 GMT

Hi,

Here's my test, on v0.9.2 of the nRF54L15-DK:

sample: nrf/samples/boards/nordic/system_off

Have you tried different multimeters and measure the same?

Did you try other firmware to enable sysoff?

[quote user=""]Right after the DCDC is enabled inside the SystemInit()[/quote]

SystemInit does not explicitly enable DCDC:

https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/mdk/system_nrf54l.c#L71

You need to enable it via this register:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/regulators.html#register.VREGMAIN.DCDCEN

Kind regards,

Håkon

RE: nRF54L15-DK suspiciously high sleep current

Albun — Wed, 13 Aug 2025 06:27:43 GMT

Hi,

here is the screenshot of my current measurement software - the measurement was done for the system_off sample from

..\sdk-zephyr-main\samples\boards\nordic\system_off. Consumption looks the same, about 32.4 uA – like the one I measure on my test firmware I described in the previous posts - when shutting off memory (NRF_MEMCONF->POWER[i].CONTROL = 0x00) for SYSTEM OFF mode.

The next picture just shows a zoomed-in part of graph, to show the DC/DC in action – the spikes are at about 110ms distance – those are suck-ups by DC/DC, it is expected. But still, the average current is about 32.5uA

On next two pictures is my actual setup for the current measurement. I use custom made current measurement board as well as software, developed by me, which receives samples from the measurement PCB and draws graphs, makes average current calculations, etc.

The sensor element used is the INA229 chip. So, current goes though the shunt resistor, and voltage drop is measured by the INA229 chip. The PCB on photo has 3 Ohm shunt resistor installed.

To be clear, here is the part of the current sensing schematics of the above mentioned device (though on schematics there is 1 Ohm shunt specified, never mind it):

This setup I use for more than a year on other projects, and it is proved functional. For example, I also tested the ProMicro PCB (the cheap device, can be found on aliexpress) - based on the Nordic nRF52840. Having removed the LDO chip from that PCB (since it draws few uA itself), I power that PCB from an external 3.6V battery and measure 1-2 uA when chip is in sleep mode, which is totally in sync with the specifications.

But here, on nRF54L15DK, as I've already said, current is 32-35 uA. I have even excluded the possibility of some really exotic case (but on such stage of research for the problem, one already starts blowing on the water) like taking into account, that board is powered from USB port from the same domain as my current measurement board (which is also attached to USB), so if there are some side currents flowing... I don't know. Anyway, I disconnected USB cable from the nRF54L15DK and attached a 4.2V Li-Ion battery as the power source instead - thus now it is 100% standalone operation of the board.

But, results are totally same as before - the consumption graph in this case is not influenced at all, looks exactly like the one from the very first picture here, and same 32-35 uA in sleep mode (32uA if I shutdown memory in system off mode and 35 uA if I leave it on default settings)

P.S. Also, as to the second link - about prerequisites for setting up the DK for current measurements - there are two advises like "Consider disconnecting the virtual serial port connections..." - which is kinda not clear to me how those can influence, since those analog switches are powered from the VDD_DBGR power domain, which in its turn is derived from transitor buffer, and does not belong to the VDDM_nRF domain. Whatever state of nRF5340's VCOM pins/ports is irrelevant, since nRF54L15 after reset has all GPIOs disconnected and I don't see how this can increase sleep current up to 32-35uA. But ok, I tested in JLink, I did "VCOM disabled" command - and of course this didn't change the current problem.

RE: nRF54L15-DK suspiciously high sleep current

Håkon Alseth — Fri, 08 Aug 2025 12:36:44 GMT

Hi,

Can you share a picture of how you measure current?

Have you tried the system off sample that we have in the SDK? https://github.com/nrfconnect/sdk-zephyr/tree/main/samples/boards/nordic/system_off

When using the DK, it is important that you follow the prerequisites here:

https://docs.nordicsemi.com/bundle/ug_nrf54l15_dk/page/UG/nRF54L15_DK/measurements/set_up_dk.html

Kind regards,

Håkon

RE: nRF54L15-DK suspiciously high sleep current

Albun — Thu, 07 Aug 2025 06:37:16 GMT

While waiting yet for some insights from other people, here is little more info on the situation.
I have made experiments with MEMCONF and sleep modes - SYSTEM ON IDLE and SYSTEM OFF.

The SYSTEM OFF I initiate in this way:
NRF_RESET->RESETREAS = 0x03FFF;
NRF_CLOCK->TASKS_XOSTOP = CLOCK_TASKS_XOSTOP_TASKS_XOSTOP_Trigger;
NRF_POWER->TASKS_LOWPWR = POWER_TASKS_LOWPWR_TASKS_LOWPWR_Trigger;
NRF_REGULATORS->SYSTEMOFF = REGULATORS_SYSTEMOFF_SYSTEMOFF_Enter;

The SYSTEM ON IDLE I do using this loop:
while (true)
{
__WFI();
__WFE();
}

By default, out of reset, MCU has MEMCONF's CONTROL,RET,RET2 set to 0xFFFFFFFF, which means all RAM blocks are to be powered ON and to be kept retained in SYSTEM OFF mode.
The following tests I did by programming firmware to MCU first, then pressing the reset Button, then measured current within VDDM_nRF cirquit:

1. All RAM blocks are configured to be powered OFF in the SYSTEM OFF mode.
NRF_MEMCONF->POWER[0].CONTROL = 0x00000000;
NRF_MEMCONF->POWER[1].CONTROL = 0x00000000;

After this, SYSTEM OFF is initiated.
Consumption: ~32.280 uA


2. All RAM blocks are left to default settings in the MEMCONF's CONTROL.
NRF_MEMCONF->POWER[0].CONTROL = 0xFFFFFFFF;
NRF_MEMCONF->POWER[1].CONTROL = 0xFFFFFFFF;

After this, SYSTEM OFF is initiated.
Consumption: ~34.416 uA

It is clear that MEMCONF influences the consumption current in sleep mode by about 2-2.5uA, which approximately coinsides with the MCU's PDF (Electrical Specification).
But remain those extra 32 uA - which part still consumes so much energy???

RE: nRF54L15-DK suspiciously high sleep current

Albun — Wed, 06 Aug 2025 21:16:15 GMT

Also, I forgot to mention that current is measured after programming and pressing reset button on the board. So measurement takes place when device is not in the debug mode