nRF5340 takes too long from Power ON to start executing the main application

[neo_here]

Hi, we have a custom nRF5340 based device. Has NISB and MCUBoot Enabled. It takes about 2.5 seconds to get into the application and BLE advertisement to start.

Wanted to know how do we go about narrowing down the cause and potential solutions.

We are on nRF Connect SDK 2.6.1

[Elfving]

Hi, 

The first two things from the top of my head of things to try, is to see if you get the same results with the same sw on a nRF5340DK, and if you get the same with a default sw on your board. Do you have a DK? And could you try a sample?

Regards,

Elfving

[neo_here]

Was able to test a sample on the DK and our board

1) DK, Pretty quick most of the time, did see a couple instances where it took about 500ms but that was about 1 in 10 times. Most times it was pretty quick




2) Same Sample on our board, seems to consistently take about 1 second or more to first advertisement. This is much lower than 2.5 seconds but I'm guessing the bootloaders also add some overhead in that scenario. 




Do you think the Power/Clock subsystems are taking much longer to stabilize on our board? Also how to lower the time taken by the bootloaders themselves? 

Also does the current draw pattern suggest anything for our board for why it's taking so much longer. 

[neo_here]

Yes, the HW hasn't changed after this point. 

[neo_here]

Elfving   Did some more experiments and I see this for time taken at each of the stages. NSIB starts executing immediately and seems like it's MCU boot which is taking quite a while to find the image and jump to the image. This is on our board with the production firmware. 

*** Booting NSIB v3.5.99-ncs1-1 ***
Attempting to boot slot 0.
Attempting to boot�*** Booting NSIB v3.5.99-ncs1-1 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8000.
Verifying signature against key 0.
Hash: 0x40...26
<<<Above loads within 16ms of power ON>>>

Firmware signature verified.
Firmware version 1
�Booting (0x8000)
<< +150ms >>>

*** Booting mcuboot v3.5.99-ncs1-1 ***
I: 12 Sectors of 4096 bytes
I: alloc wra: 0, f40
I: data wra: 0, f4
I: qspi_encryption_config
I: qspi_encr_setup OK
I: Starting bootloader
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
<< +600ms >>

I: Bootloader chainload address offset: 0x28000
I: Jumping to the first image slot
<< +1100ms >>

[00:00:00.002,349] <dbg> qspi_nor: configure_chip: RDSR 40 QE 1 need 1: no-change
*** Booting application v3.5.99-ncs1-1 ***
[00:00:00.010,620] <inf> fs_nvs: 12 Sectors of 4096 bytes
[00:00:00.010,620] <inf> fs_nvs: alloc wra: 0, f40
[00:00:00.010,650] <inf> fs_nvs: data wra: 0, f4
[00:00:00.011,840] <inf> qspi_encr: qspi_encr_setup OK
<< +512ms >>

[neo_here]

I added some more timestamps in MCUBoot and seems like it spends more than a second just in mcuboot main()

uart:~$ *** Booting NSIB v3.5.99-ncs1-1 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8000.
Verifying signature against key 0.
Hash: 0x40...26
Firmware signature verified.
Firmware version 1
�*** Booting mcuboot v3.5.99-ncs1-1 ***
I: 12 Sectors of 4096 bytes
I: alloc wra: 0, f58
I: data wra: 0, d0
I: qspi_encryption_config
I: qspi_encr_setup OK
I: Entering MCUBoot Main uptime -> 289
I: Starting bootloader
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
I: Bootloader chainload address offset: 0x28000
I: Jumping to the first image slot
�: Till Before do_boot  uptime -> 1429

[Elfving]

Have you tried this on more than one board and nRF?

There are things that can make the boot-up take longer, like eg. SD card initialization, or a missing DC/DC Converter. But if what you are running on the custom board is exactly that same as what is running quickly on the DK, and the two are otherwise the same then I guess that's not the problem. 

neo_here said:

seems like it's MCU boot which is taking quite a while to find the image and jump to the image. This is on our board with the production firmware. 

I assume you are not using SD card for MCUBoot? And everything regarding MCUBoot was the same on the DK?

Regards,

Elfving

[neo_here]

No we don't use SD Card. We use QSPI with an encrypted external flash. 

[Elfving]

Could you try disabling the external flash on the board, to see if that makes a difference?

Regards,

Elfving