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 measure a difference in timing between speed and debug optimizations.
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!