High Power consumption issue in Nrf54L15 during system off (low power state)

[CYRUS AG]

Hi,

I am facing a power consumption issue with the nRF54L15 (BM15C SoC) in deep sleep (System OFF / low-power state). The measured current consumption is approximately 221.6 µA.

I am using the System OFF sample from the nRF Connect SDK:
https://github.com/nrfconnect/sdk-zephyr/tree/ncs-v3.2.2/samples/boards/nordic/system_off/

This value appears significantly higher than expected based on the datasheet:
https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/chapters/current_consumption/doc/current_consumption.html

We recently migrated the hardware from an ESP32-C3-Mini-1 SoC to the BM15C SoC. On the same hardware setup, the ESP32-C3 consumes around 8 µA in deep sleep. Since the hardware design remains unchanged, we believe the issue is not hardware-related. However, with the nRF54L15 on the same setup, the deep sleep current remains high at 221.6 µA.

We are using nRF Connect SDK v3.2.2.

Could you please help identify possible causes or recommended checks to achieve the expected low-power consumption?

Thanks.

[Syed Maysum Abbas Zaidi]

Hi,

The issue could be due to RAM retention, you may need to disable it which should not be a issue as chip will reset upon wakeup. To make this happen, can you try adding the following lines before calling system OFF:

NRF_MEMCONF->POWER[0].RET = 0;
NRF_MEMCONF->POWER[1].RET = 0;
NRF_MEMCONF->POWER[0].RET2 = 0;
NRF_MEMCONF->POWER[1].RET2 = 0;

You may able to reduce the extra current consumption.

Best Regards,
Syed Maysum

[CYRUS AG]

Hi Syed,

I have tried the above lines, but the results are the same (216.4 µA). It didn’t work at all. Also, I have tried this on another identical device to ensure the device is working properly, but the results are the same.

Thanks!

[Syed Maysum Abbas Zaidi]

Hi,

Okay, it looks we may need to confirm if the sample is actually entering the System OFF. Can you check the logs or if possible to share it as in the system_off sample, System OFF is entered only if console suspend succeeds. If console suspend fails, the app prints "Could not suspend console" and returns without calling sys_poweroff().

Similarly when waking up there should be a message confirming it. 

Best Regards,
Syed Maysum

[CYRUS AG]

Hi Syed,

I have checked the logs, and the device is entering System OFF. However, there is no significant difference in current consumption — the result remains around ~220 µA.

Here is sample,
6254.system_off.zip

Thanks!

[Syed Maysum Abbas Zaidi]

Hi, 

Hi, thanks for confirming. When measuring the System OFF current, could you please confirm whether this was done with the debugger/SWD physically disconnected and with RTT disabled? A connected debug probe can significantly affect low power current measurements.

As the next check, could you also try building with all wake sources disabled by adding the following to your prj.conf:

CONFIG_GPIO_WAKEUP_ENABLE=n
CONFIG_GRTC_WAKEUP_ENABLE=n
CONFIG_LPCOMP_WAKEUP_ENABLE=n

We want to rule out a case where a wake source (GPIO level wake or GRTC) is active continuously, causing the device to enter System OFF and then wake immediately in a loop, which can show up as a much higher current. With all wake sources disabled, the device should enter System OFF and stay there until reset/power-cycled.

Please measure the current in this configuration and let us know the result, along with how the board is powered and where exactly you insert the ammeter or PPK.

Best Regards,
Syed Maysum

[CYRUS AG]

Syed Maysum Abbas Zaidi said:

Please measure the current in this configuration and let us know the result, along with how the board is powered and where exactly you insert the ammeter or PPK.

Hi Syed,

Thanks for the suggestions.

I tested with the recommended changes in prj.conf. This time I checked the behavior with J-Link connected, and the results are still similar. During the ON state, the consumption is around 4.20 mA, and in System OFF it initially shows about 219.2 µA, but after waiting for around 5 to 8 seconds, the current drops to 83.8 µA(this happens occasionally).

Without J-Link connected, the ON state consumption is again 4.20 mA, but the device does not appear to enter System OFF based on the current measurement. This is my observation so far.

For reference, this is my prj.conf configuration:

CONFIG_PM_DEVICE=y
CONFIG_GPIO=y
CONFIG_POWEROFF=y
CONFIG_HWINFO=y

CONFIG_USE_SEGGER_RTT=n
CONFIG_RTT_CONSOLE=n
CONFIG_UART_CONSOLE=n

CONFIG_GPIO_WAKEUP_ENABLE=n
CONFIG_GRTC_WAKEUP_ENABLE=n
CONFIG_LPCOMP_WAKEUP_ENABLE=n

The ammeter is connected in series between the battery(3.7V, 120mA) and the device for measurement. Tests are performed both with J-Link connected (for logging/behavior verification) and with it disconnected.

Please let me know if you would like me to check anything else.

Thanks!

[CYRUS AG]

Additionally, I tried applying the change in the overlay DTS, but the results remain the same as mentioned earlier.

I added the following,

&vregmain {
regulator-initial-mode = <NRF5X_REG_MODE_DCDC>;
};

However, there was no observable difference in current consumption.
 

[Syed Maysum Abbas Zaidi]

Hi,

Thanks for sharing your observations.

You now may need to check the build code of your SoC as there is a nRF54L15 errata which says: if entering System OFF too soon after pin reset/power cycle, current can be higher than expected.

If your SoC build code is one of the following: QFAA-C00, CAAA-C00, QDAA-C00, QGAA-C00 or QFAA-BB0, CAAA-BA0 then try applying the following workaround.

Right before the sys_poweroff(), add:

*(volatile uint32_t *)0x5005340C = 1;

/* Ensure at least 40 CPU cycles before entering System OFF.
 * A simple NOP loop or a small delay function is enough.
 */
for (volatile int i = 0; i < 100; i++) {
    __NOP();
}

sys_poweroff();

Best Regards,
Syed Maysum

[CYRUS AG]

Syed Maysum Abbas Zaidi said:

nRF54L15 errata

https://docs.nordicsemi.com/bundle/errata_nRF54L15_EngB/page/ERR/nRF54L15/EngineeringB/latest/err_L15_new.html

I also tried the workaround mentioned in the nRF54L15 Engineering B errata documentation, but there is no change in the results.

[Syed Maysum Abbas Zaidi]

Hi,

Okay, thanks for keep trying out the possible solutions.

It means even after disabling the RAM retention, all wakeups sources and implementing Errata 37 workaround, there is no change in the results. Then we need to be be sure you are measuring current only into the BM15C supply pin(s), not the whole board rail or hardware setup (so the ammeter only sees the SoC, not the rest of the board). Also temporarily disconnect or powergate any other loads on that rail.

Measure and see if you see any drop in current.

Best Regards,
Syed Maysum