Reduce MCUBoot startup time

[Yeccc]

We found that it took a long time for the nrfconnect sdk to power on the device to enter the application.
Is there any way to reduce the startup time?

We have closed the log, and the startup time has reached 1.3s.
It is too long for the bulb device, so we need to solve this issue.

[Vidar Berg]

Hi,

Please try to select the RNG — Random number generator as the entropy source instead of using the CRYPTOCELL — ARM TrustZone CryptoCell 310 (default) by adding the following to your board DT file (or in an overlay):

	chosen {
		zephyr,entropy = &rng;
		};

This accounts for about 400 ms of the startup time according to the thread here:  High Current 400ms+ Startup Delay BLE Beacon Using RC Oscillator 

What signature type have you selected for MCUBoot, RSA or ECDSA_P256?

Best regards,

Vidar

[Yeccc]

Thank you for your help.
RNG is set by default in the nrf52840dk_nrf52840.overlay.

And the signature type is ECDSA_P256, it's also set by default on the nrfConnect SDK of 2.1.1 version.

We expect the startup time to be reduced to 500ms,

this is very important for our bulb product. Please help solve it as soon as possible. Thanks a lot.

# MCUBoot settings
#
# CONFIG_SINGLE_APPLICATION_SLOT is not set
# CONFIG_BOOT_SIGNATURE_TYPE_NONE is not set
# CONFIG_BOOT_SIGNATURE_TYPE_RSA is not set
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

[Vidar Berg]

Hi,

What SDK sample is your project based on? Is it Matter, Homekit, or something else? And how do you measure the startup time? 

[Yeccc]

Our project is based on the light_bulb.
It's a matter over thread project.

We output GPIO high level in Main application, and then use oscilloscope to check the time difference between 3.3V power supply and GPIO.

[Vidar Berg]

Thanks for confirming. I measure 1.1 second here with the original sample project between systeminit() in MCUBoot and app main(). I am checking internally if there is a way to optimize this. 

Edit: for me to better understand the problem, could you say something about how this delay affects your application? For instance, if your app requires frequent reboots? 

[Yeccc]

The bulb device needs to be on soon after being powered on;

In addition, our bulb device is restored to factory settings through multiple power on/off sequences, and too long startup time will also affect the user experience.

I really hope you can solve this issue. Thanks a lot.

[Vidar Berg]

Thank you for explaining the reason you are looking to reduce the startup time. This is valuable feedback which I will relay to the developers. 

I was able to significantly reduce the startup time now by disabling boot validation that takes place on every reboot by default, and by changing the default clock configuration.

Here are my results:

#1 with RCOSC as LF clock source

Settings added to MCUBoot build:

- CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

- CONFIG_BOOT_VALIDATE_SLOT0=n

In light bulb app:

 

- CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

#2 with LFXO as LF clock source

Settings added to MCUBoot build:

- CONFIG_SYSTEM_CLOCK_WAIT_FOR_STABILITY=n

- CONFIG_BOOT_VALIDATE_SLOT0=n

In light bulb app:

 

- CONFIG_SYSTEM_CLOCK_WAIT_FOR_STABILITY=n

You may also consider using the SYS_INIT() macro for functions that may benefit from being run before main().

[Yeccc]

Thanks for your support.

Does this have any other impact?

[Yeccc]

Could you confirm it?
Does this modify have other effects?

[Vidar Berg]

Which configuration did you want to use, the one with LFXO or LFRC? 

[Yeccc]

The first configuration, it seems to reduce more startup time.
Does this modify have other effects?

[Vidar Berg]

I cannot think of any major drawbacks with selecting RCOSC clock source for this application. The average sleep current will increase slightly since the RCOSC source requires periodic calibration against the HFXO source (~1.5 uA), but I assume the bulb is mains powered. The RCOSC is also less accurate as you can see from the el. spec. here: Low frequency RC oscillator (LFRC).