STM32F030: Delayed startup when the MCU is warm - Oscillator or clock issue?

[MERSI]

Hi everyone,

I'm currently investigating an interesting issue with an STM32F030 and would appreciate some insights.

I've noticed that when the processor gets warm, it takes noticeably longer to start up properly and begin executing the main software (takes longer in my bootloader state - displayed via LED). Once it's running, it seems fine, but the boot delay is definitely temperature-dependent.

Has anyone experienced this before? I have two main questions regarding this behavior:

1. General Execution Speed: Can the processing speed actually be affected by the heat? Meaning, does the MCU generally execute code slower when warm, or is the clock strictly fixed once running?

2. Startup / Stabilization Phase: Is it more likely that the MCU is just waiting longer during the initial boot phase? For example, could the startup delay be caused by the internal oscillator (HSI) or external crystal (HSE) taking longer to stabilize, or the voltage/POR circuits reacting differently to the temperature?

I suspect it might be stuck a bit longer in the clock initialization loop waiting for a "ready" flag, but I'd love to hear if this is a known characteristic of the STM32F030 series.

Thanks in advance for your help!

[mƎALLEm]

Hello,

Need to provide more details about the case.

1- When you say " bootloader state - displayed via LED". Do you mean a custom bootloader?

2-  Warm at which level? did you measure the ambient temperature of the chip?

Meanwhile, if you are using HSE with a crystal with a custom bootloader if you are using it, you need to ensure that the crystal you are using is compatible with the MCU. Please refer to the AN2867 "Guidelines for oscillator design on STM8AF/AL/S and STM32 MCUs/MPUs"

or this knowledge base article (reduced form of the previous application note): How to select a compatible crystal and load capacitors for STM32 with layout guidelines

[Ozone]

> I've noticed that when the processor gets warm, ...

What temperatures we are speaking of here, 30°C, 50°C, 80°C ... ?

> I suspect it might be stuck a bit longer in the clock initialization loop waiting for a "ready" flag, ...

I would recommend to add instrumentation code (i.e. GPIO pin toggle) while you wait for the HSE ready flag, and measure both cases with a scope or logic analyzer.

I would rather suspect the quartz / oscillator causing the issue.

Perhpas you can selectively warm up components as a second step to identify the one causing the issue.

> ...takes longer in my bootloader state ...

Are you doing any Flash erase/write operations in your bootloader regardless ?

[MERSI]

It's been my fault. It is an external device (IC) that keeps me in an interrupt function at startup (at high temperatures).

Thanks for your help :)

[MERSI · Accepted solution]

It's been my fault. It is an external device (IC) that keeps me in an interrupt function at startup (at high temperatures).

Thanks for your help :)