Boot up time of NCS application

[trafficode]

Hello,

I'm on development stage of product based on nrf52833.

For now, critical thing for me is boot up time. Device has to be ready about 150ms since VDD appear.

MCUBOOT is enabled(software update is also required).

My measurements looks as below(after all of improvements that I found):

Single application without MCUBOOT compiled: 8ms

APPL+MCUBOOT: 225ms

mcuboot.conf

CONFIG_MULTITHREADING=y
CONFIG_LOG=n
CONFIG_CONSOLE=n
CONFIG_PRINTK=n
CONFIG_SHELL=n
CONFIG_SERIAL=n
CONFIG_FLASH=y

Those lines are included in my custom board _defconfig file:

#RC as Low Frequency clock

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y

I also saw:

 Boot time for Zephyr /w bootloader. 

 MCUBOOT Boot time 

With those information I can't reach better boot up time. This boot up time is very important, I can even say that critical to meet requirements. 

Are there any new possibilities to speed up this process? Can I resign with something or do something more? 

I have to achieve ~70-80ms less than it is right now...

Are there any suggestions to reduce this delay?

Second important questions is: Does this time will depends on given sample of mcu in significant degree?

[Sigurd]

Hi,

1) How are you measuring this? Is it when you e.g. reach main() in your app?

2) Can you elaborate on what makes it critical you start up very fast? Do you need to e.g. set some GPIO pin high within x time, or send some data over UART, etc ?

[trafficode]

I set gpio pin when I reach while(1){} in main(). It means that pin is set if device is initialized and ready to work. Then I observe VDD and this pin on oscilloscope. Thats haw I'm doing boot up measurements.

Why it is critical... Device is based on DALI interface. Standard require that device/driver has to answer to query no longer than 450ms after mains appear on device. And this procedure(power cycle and query) is automated by certified by "DALI Alliance" tester device. To meet worldwide requirements and to put sticker into device I need to met this requirement...

Specific electronics gives 300ms overhead between mains and vdd appear. Thats why 150ms is so critical.

[Sigurd]

From start-up, until main() in the application is reached, you have all the PRE_KERNEL_1 , PRE_KERNEL_2 , and POST_KERNEL initialization. The device drivers you are using are initialized before your main() function. E.g. if you using the serial driver in your application, then the UART is initialized at PRE_KERNEL_1 level. The more drivers and things that are enabled, the longer time it will take.

I'm not sure what this DALI interface is, but in theory it could be up and running and be responsive before you reach main().

Also, with MCUBoot, it will take longer before your application boots.
MCUBoot will e.g. validate the signature of the image that it will boot, and this takes a bit of time.
You can try to speed up the boot process by setting CONFIG_BOOT_VALIDATE_SLOT0=n and/or BOOT_VALIDATE_SLOT0_ONCE=y https://github.com/nrfconnect/sdk-mcuboot/blob/v1.9.99-ncs3/boot/zephyr/Kconfig#L178

[trafficode]

Sigurd said:

From start-up, until main() in the application is reached, you have all the PRE_KERNEL_1 , PRE_KERNEL_2 , and POST_KERNEL initialization. The device drivers you are using are initialized before your main() function. E.g. if you using the serial driver in your application, then the UART is initialized at PRE_KERNEL_1 level. The more drivers and things that are enabled, the longer time it will take.

I know it. Like I mentioned in first post: application without MCUBOOT boot up in 8ms, so thats the time of booting only the application, peripheralls etc. So there is no significant optimization to reach. 

DALI(Digital addresable lighting interface): two wire serial interface.

https://www.dali-alliance.org/

CONFIG_BOOT_VALIDATE_SLOT0=n helped a lot. Now boot up time is about 10ms: APPL+MCUBOOT.

But each stick has two ends. What I'm loosing in this approach?

• CONFIG_BOOT_VALIDATE_SLOT0 controls whether MCUboot validates the signature of the booted image on every boot (or just when upgrading). This can be disabled to make the boot process slightly faster, at the cost of no longer verifying a path of trust to the running image.

It seems to be still secure, do You know some additional bad sides?

[Sigurd]

Hi!

As far as I can tell, it's mainly a tradeoff between boot time and security. i.e. as mentioned in the Kconfig help text: https://github.com/nrfconnect/sdk-mcuboot/blob/v1.9.99-ncs3/boot/zephyr/Kconfig#L178