Regarding the startup current of the nRF54L bootloader

[talby]

Hi,
I am developing a program for the nRF54L15 with the DFU bootloader enabled.
I would like to reduce the startup current.

I am using SDK 3.2.4.

The `sysbuild.conf` settings are as follows.

SB_CONFIG_BOOTLOADER_MCUBOOT=y

SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="\${APP_DIR}/private_key.pem"

SB_CONFIG_BOOT_SIGNATURE_TYPE_ED25519=y

SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=y

SB_CONFIG_MCUBOOT_GENERATE_DEFAULT_KMU_KEYFILE=y

The `mcuboot.conf` settings are as follows.

CONFIG_SERIAL=n

CONFIG_BOOT_VALIDATE_SLOT0=n

CONFIG_SPEED_OPTIMIZATIONS=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

When booting with these settings, an average current of 1.8 mA flows for a period of approximately 470 ms, as shown in the image below.

What operation is causing this current draw?

Is it possible to further reduce the current or shorten this duration?

Best regards.

[Simonr]

Hi

Sorry about the late reply here. I am currently looking into whether the start-up current consumption can be lowered further, but haven't found anything as of yet. I expect to have more of an answer for you by early next week at the latest. Thank you for your patience.

Best regards,

Simon

[talby]

Dear Simon

Thank you for your reply.

Upon further investigation, it appears that the startup current of the nRF54L is significantly influenced by the SDK version, even when no bootloader is present.

Here is a comparison of the startup current for `peripheral_lbs`.

`prj_minimal.conf` is being used.

V2.9.1

V3.2.4

V3.4.0

Although we have not yet investigated the bootloader specifically, the fact that the current varies depending on the SDK suggests that a software-based solution is possible.
We plan to update our project to V3.4.0 in the future.

but we are hoping to achieve current levels comparable to those seen in V2.9.1.

Best regards,