Out-of-spec temperature behavior of STM32F412 (hard fault) ?

Tell us about the power supply and clocks you are using.

Could you try this on a "known good" board such as Nucleo?

JW

The reset is caused by the watchdog when the MCU gets stuck in the hard fault handler.

The +3.3V is delivered by a LP38693MP-3.3 (500mA). I probed with a scope, there is not supply dip when or before the fault occurs.

A 25MHz external crystal is used. I've also probed the crystal which doesn't seem to stop oscillating except for a short time when the fault occurs in debug only. The DC drops to 0 so I expect the crystal driver just stops when the debugger pauses.

With no debugger, the MCU stalls but the crystal doesn't stop oscillating.

The chip package is LQFP-64 and doesn't seem to match the evaluation boards for this family.

I think I will try different firmwares, enabling or disabling some peripherals and use internal RC clock instead to try to get more insight into the cause.

Flash wait states and prefetch tend to represent the critical paths resulting in execution failure and hard faults.​

> Flash wait states and prefetch tend to represent the critical paths resulting in execution failure and hard faults.​

+1

Add also a different PLL setting (e.g. lower M & lower N) to the experimentation mix.

Do the "problematic" samples differ from the "non-problematic" ones, e.g. in datecode or other aspects of marking?

JW