We are waking on GPIO change, and have measured a 2.129 second from the GPIO trigger to main() running on a nRF5340, with bootloader and Zephyr, running on internal oscillator.
Is this in line with what other people have observed?
Any suggested ways to deduce the delay?
Hi,
I do not know enough about your system to say exactly what causes the long boot time, but there are a number of things that can affect it:
What is the expected time for startup for a typical app? can you give an expected range?
Logging - do not have any logging from the boot loader and zephr. this is the 1st logging seen
[00:00:00.001,617] <inf> mcumgr_zephyr_grp: Registering Zephyr basic mgmt group
[00:00:00.001,770] <inf> MAIN: main() go
#############################################
# Soft Ver 0.0.6+4
# reset reason wakeup GPIO E3
#############################################
[00:00:00.001,922] <inf> REMOTE: Initializing bluetooth...
LFRC clock - we are waking up via a GPIO, would like clock have been turned off. around how much time?
MCUBoot - we are using DFU, is the delay required for DFU, how long?
Boot validation
$ mcuboot
swap type: none
confirmed: 0
primary area (2):
version: 0.0.6+4
image size: 206472
magic: unset
swap type: none
copy done: unset
image ok: unset
Hi,
Dwayne Forsyth said:What is the expected time for startup for a typical app? can you give an expected range?
That depends greatly on the configuration. Everything from some milliseconds to a few seconds.
Perhaps I misunderstood the reference to internal oscillator. Was that just the HFINT, or also LFRC (which I assumed)? If you use the 32.768 kHz crystal oscillator, that alone can add up to 500 ms to the startup time alone (you can test by adding CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to your prj.conf).
Another factor I forgot to mention is the CryptoCell library initialization, which takes a lot of time. If you don't need an entropy source, you can speed that up by adding the config CONFIG_ENTROPY_CC3XX=n.
Dwayne Forsyth said:LFRC clock - we are waking up via a GPIO, would like clock have been turned off. around how much time?
That depends on your configuration and which low power mode you are using. Normally, the LF clock is running when in system ON low power mode, as that is needed for time keeping so that. But as you describe a startup here, I assume you are waking from system off low power mode, and in that case the startup is in form of a reset etc. So the LF clock must be started. (This is not needed to service interrupts etc so for interrupt latency it is different, but for system startup time this is what matters and the HF clock startup time can be ignored in this context). Typical startup time of LFRC is 310 ms, but it can be up to 500 ms.
Dwayne Forsyth said:MCUBoot - we are using DFU, is the delay required for DFU, how long?
It is not needed for DFU, but it is needed for serial recovery (which is one of several methods to enter DFU mode, where the device can simply wait a short amount of time before booting the application to see if a DFU operation is initiated via the DFU interface). The default value of USB_DFU_WAIT_DELAY_MS is 12000 ms.
Hi,
Dwayne Forsyth said:What is the expected time for startup for a typical app? can you give an expected range?
That depends greatly on the configuration. Everything from some milliseconds to a few seconds.
Perhaps I misunderstood the reference to internal oscillator. Was that just the HFINT, or also LFRC (which I assumed)? If you use the 32.768 kHz crystal oscillator, that alone can add up to 500 ms to the startup time alone (you can test by adding CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to your prj.conf).
Another factor I forgot to mention is the CryptoCell library initialization, which takes a lot of time. If you don't need an entropy source, you can speed that up by adding the config CONFIG_ENTROPY_CC3XX=n.
Dwayne Forsyth said:LFRC clock - we are waking up via a GPIO, would like clock have been turned off. around how much time?
That depends on your configuration and which low power mode you are using. Normally, the LF clock is running when in system ON low power mode, as that is needed for time keeping so that. But as you describe a startup here, I assume you are waking from system off low power mode, and in that case the startup is in form of a reset etc. So the LF clock must be started. (This is not needed to service interrupts etc so for interrupt latency it is different, but for system startup time this is what matters and the HF clock startup time can be ignored in this context). Typical startup time of LFRC is 310 ms, but it can be up to 500 ms.
Dwayne Forsyth said:MCUBoot - we are using DFU, is the delay required for DFU, how long?
It is not needed for DFU, but it is needed for serial recovery (which is one of several methods to enter DFU mode, where the device can simply wait a short amount of time before booting the application to see if a DFU operation is initiated via the DFU interface). The default value of USB_DFU_WAIT_DELAY_MS is 12000 ms.
Hi Einar
I'm dealing with a similar issue, developing a device on a nRF5340DK where boot up time is critical.
Coming from SOFT_OFF till fully booted, I'm experiencing around ~400ms from the wake up interrupt is triggered until the device is fully booted.
Is there any way of optimizing this? And what is causing the boot up time?
For now the application developed is fairly simple.
I already added CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y, which brought boot up time down from around ~850ms to ~400ms.
If you use the 32.768 kHz crystal oscillator, that alone can add up to 500 ms to the startup time alone
Is there a better way of clocking the nRF5340DK, to speed up boot up time?
Thanks
Hi,
Changing to the LFRC as you have done is the most important single factor for reducing the boot up time. Another important factor is to disable UART logging, as that typically introduce a significant delays. Regarding other ways to clock the nRF, there is the option to use CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH so that the LF clock is synthesized from the HF clock. That is not suitable for a low power device though, and should not result in a significant improvement in boot time compared to using the LFRC.
Other than that, there are many other application specific factors that affect boot up time, as most of the Zephyr drivers and services will be started before main runs.
