cancel
Showing results for 
Search instead for 
Did you mean: 

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

MLiis.1
Associate II

Hi all,

I am testing product samples fitted with STM32F412RET6 which has a temperature operating range of -40°C +85°C.

On some samples tested inside a climate chamber, the MCU unexpectedly reset due to cold temperature within operating range (e.g. -5°C).

I have reproduced this behavior with a freeze spray and used the debugger to see what really happens.

When abruptly cooled with the spray, some MCUs issue a hard fault. Those are the same that fail inside the chamber.

The faults don't seem to originate from a certain spot in the code.

It really seems that the chips are involved as I have unsoldered, resoldered and switched two chips (one good and one bad) and the problem followed the chip.

The firmware is the same as the chip revision.

Did you ever experience something similar ?

1 ACCEPTED SOLUTION

Accepted Solutions
MLiis.1
Associate II

Thank you both for your suggestions !

After a lot of headaches, I found out that the mounted decoupling capacitor for node VCAP1 was 22nF instead of recommended 4.7uF (quite a large difference !).

I overlooked that node when checking supplies.

ML

View solution in original post

6 REPLIES 6

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

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

JW

MLiis.1
Associate II

0693W000008xst5QAA.pngThe 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.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

> 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

MLiis.1
Associate II

Thank you both for your suggestions !

After a lot of headaches, I found out that the mounted decoupling capacitor for node VCAP1 was 22nF instead of recommended 4.7uF (quite a large difference !).

I overlooked that node when checking supplies.

ML

You work with this guy, evil twin, or just Spooky Action at a Distance?

https://community.st.com/s/question/0D53W00000hNkoDSAS/unable-to-run-stm32f401-at-84-mhz-sysclk-works-fine-at-48-mhz

Thanks for circling back to provide closure here.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..