MCUboot - Long startup time from VDD On to sys_init EARLY

[smith_tristan]

Hello,

We have an NCS v2.2.0 nRF5340 application with MCUboot that requires GPIO control of a few pins extremely early in the startup process. We have a signal "A" pulled high externally, and the MCU is responsible for driving it low as soon as possible (well before the Zephyr drivers come up in MCUboot).

 

So we have a Zephyr sys_init EARLY hook in our MCUboot child image that drives that pin low (using NRF HAL) before anything Zephyr starts up, right after we enter the C domain. 

 

Unfortunately we're still seeing a lot of time before we even get to that EARLY hook... on the order of 100ms.

Here's a scope shot of the dev kit running our application and MCUboot. In this screenshot, VDD and "A" come up from power down, and then "A" driven low in the EARLY hook in MCUboot: 122ms from VDD to EARLY. Note that this is all before MCUboot main.c is called (and before our application starts). Blue is VDD, Yellow is "A":

 

 And here's our board, ~114ms from VDD to EARLY hook. Blue is BATT+ and Yellow is "A":

 

 We are using NCS v2.2.0 (for now...). We are using the RC LFCLK, "CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y". See attached for MCUboot's autoconf.h. I believe we've picked our HFXO internal caps correctly after double checking with our HW team.

We didn't see a difference in timing between speed and debug optimizations.

7624.autoconf.h

Any ideas what all could be happening in that 100ms time frame? Anything else we can tweak to get that time down?

Alternatively, is that 100ms timeframe deterministic and consistently around 100ms?

I also tried the same experiment by adding an EARLY sys_init to the Zephyr blinky sample application (no MCUboot), however that application got from VDD to EARLY in about 1.48ms.

Thanks for your help!

[Amanda Hsieh]

Hi, 

We are currently understaffed due to the summer vacation period, so delayed replies must be expected. I am sorry about any inconvenience this might cause.

Regards,
Amanda H.

[smith_tristan]

Thanks, please let me know if I need to clarify anything or provide more info!

[Amanda Hsieh]

Hi, 

Sorry for the late reply. We can't replicate it. 

This is ncs mcuboot with your hook on the latest main, without any config changes, can see it gets set ~4ms after Vdd rises.

You're using rsa so it shouldn't be that, I would suggest you update to main, just try your board on it with zephyr/samples/subsys/mgmt/mcumgr/smp_svr which will include mcuboot, and see what you get because I can see no problem.

NCS v2.2 is nearly 2 years old, bugs have been fixed in that time. Could you test with the latest NCS?

Another trace without using Vdd, this is with channel 0 connected to the reset button, and manually pressing the reset button:

Application output to verify it is indeed using MCUboot:

 

*** Booting MCUboot v2.1.0-dev-daf2946a0f07 ***
*** Using nRF Connect SDK v2.7.99-7142f029d6a4 ***
*** Using Zephyr OS v3.6.99-98194577de1a ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot
�*** Booting nRF Connect SDK v2.7.99-7142f029d6a4 ***
*** Using Zephyr OS v3.6.99-98194577de1a ***
[00:00:00.000,671] <inf> smp_sample: build time: Aug  8 2024 08:01:09

-Amanda H.

[smith_tristan]

Hi, thanks for the response!

Updating to NCS v2.6.1 did not resolve the issue unfortunately.

I am still trying to get that sample to run on our board, running into some configuration trouble...

However, when I create a build configuration for the NRF5340DK, add the early hook, and run on the NRF5340DK, I measure ~600ms from VDD to gpio A output asserting.

Could you zip your sample app and configuration up and share with me? I'm not sure what we're doing differently, I expected to measure the same 4ms on the dev kit at the very least 

Also, what board are you using for your measurements above?

- Tristan

[Amanda Hsieh]

Hi,

Did you test with the latest NCS? 

Just try your board on it with zephyr/samples/subsys/mgmt/mcumgr/smp_svr which will include mcuboot.

-Amanda H.

[smith_tristan]

Hi,

Updating to v2.6.1 did not resolve the issue.

I've had difficulty running that example on my board, but I did eventually get it to build and run at least far enough to hit the early hook. I can reproduce the 4ms time on our board. It stops at "Failed to open flash area ID 8 (image 0 slot 1): -19". But I can see the 4ms from VDD to GPIO set!

So I think the question is, what is different between the sample app mcuboot .config and our project's mcuboot .config that could be causing the delay. 

Any other ideas?

Thanks so much,

Tristan

[Amanda Hsieh]

You can compare the .config file under the build folder to see the differences.