Zephyr OS boot-up time for STM32U575ZI

[bhardadinesh-eaton]

We are developing the application based on zephyr version 3.1.0. We have used STM32U575ZI NUCLEO board for development. Application running without MCUboot. so, its a plain application boot time. Measured the boot up time up to main after GPIO initialization. We are getting boot-up time around ~259ms. It is too high for zephyr OS boot. Is there anyway to reduce this zephyr OS boot-up time.

E.g. We have taken one GPIO and RESET Pin to measure the time. After reset, when GPIO is up. We have measure the time difference as shown below waveform. it is around ~259ms.

[erwango]

@bhardadinesh-eaton What is your target ? Also, boot up time will depend on several factors, some of them will depend on you specific application, and mainly the hw related specificities, for instance:

• the number of devices that have to be configured
• clock configuration (PLLs need stabilization period)

In order to share the same base for measurements (and start a fruitful analysis), what is the base application you're using for measurement ?

[bhardadinesh-eaton]

@erwango Thank you! Our target is less than 5ms for zephyr OS boot up. We are trying to measure the time for Blinky LED for sample ( ..\zephyr\samples\basic\blinky ). Also, We had made our own program for LED blink and measuring time.

[erwango]

@bhardadinesh-eaton Is this issue still valid ?

[bhardadinesh-eaton]

@erwango yes, Still we are not able to reduce the time.

[erwango]

@erwango yes, Still we are not able to reduce the time.

Ok, to help investigation please provide the information requested above (and any information that could help investigation, like a way to reproduce your setup)

[bhardadinesh-eaton]

@erwango yes, Still we are not able to reduce the time.

Ok, to help investigation please provide the information requested above (and any information that could help investigation, like a way to reproduce your setup)

I have given the information. We are measuring the Blinky sample time.

[erwango]

I have given the information. We are measuring the Blinky sample time.

What about the following ?

• the number of devices that have to be configured
• clock configuration (PLLs need stabilization period)

[bhardadinesh-eaton]

@erwango , Below is required information. With Blinky example only GPIO and UART console is being configured

Using PLL 160MHZ

[bhardadinesh-eaton]

@erwango Is there any input, please let's know. We try to perform it at our end.

[erwango]

@erwango Is there any input, please let's know. We try to perform it at our end.

@bhardadinesh-eaton Sorry, but no time on our side to work on this at the moment.

[erwango]

@bhardadinesh-eaton Did you try to deactivate boot banner: CONFIG_BOOT_BANNER=n ?

[bhardadinesh-eaton]

@erwango yes, We had tried it. there is something 30ms improvement for boot up time.

[erwango]

@bhardadinesh-eaton ok, then please keep us updated on your analysis and findings to avoid losing time

[bhardadinesh-eaton]

@erwango sure. I will keep you updated related to progress.

[enthunilu]

Hello @erwango

We tried similar testing on nucleo_u575zi_q board to do certain config changes and found that, when we disable "clk_lse"

&clk_lse { status = "disabled"; };

which is by default enabled in https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/nucleo_u575zi_q/nucleo_u575zi_q-common.dtsi

There is a huge reduction in timing. Can you share some pointers on this ?

[erwango]

There is a huge reduction in timing

Thanks for the hint. Can you evaluate the gain ?

[FRASTM]

The sequence for lse activation is specific to stm32U5 serie (drivers/clock_control/clock_stm32_ll_u5.c). The specification just gives "LSESYSRDY flag is set after two LSE clock cycles."

Does a different driving-capability for the clk_lse reduce the lse clock setUp time.

        &clk-lse {
            driving-capability = <1>; /* or <3> */
        };

Note that according to the ES0499 STM32U575xx and STM32U585xx device errata "The LSE oscillator may not start or may stop in low drive mode (LSEDRV = 00). Using this mode is forbidden."