2026-01-21 7:38 AM - last edited on 2026-01-21 8:24 AM by mƎALLEm
Hi all,
our product, used in industrial traction, uses an STM32F407 MCU. In certain conditions, very hard to replicate, the MCU stucks and the watchdog does not reset the MCU. It seems completely blocked.
We're suspecting there are some EMC issue on certain brushed motors used the truck but it is not under our control.
After we remove the power supply of the board and give back the supply, the board starts to work again.
Someone suggest me some latchup phenomena and I think it could be a possible explanation. Now: how can I find what is the pin (or what are the pins) susceptible to the EMI? There could be some traces the phenomena leaves on the MCU?
Thanks!
2026-01-21 7:44 AM - edited 2026-01-21 7:47 AM
Is it possibly for you to attach a debugger to a board in this "stuck" state?
See: Best Practices for Debugging Intermittent MCU Freezes on STM32.
@Lucast wrote:We're suspecting there are some EMC issue on certain brushed motors used the truck but it is not under our control.
But the susceptibility of your system is under your control.
@Lucast wrote:how can I find what is the pin (or what are the pins) susceptible to the EMI?
Has your product undergone EMC (particularly susceptibility) testing ?
In particular, testing relevant to "industrial traction" environments?
2026-01-21 8:53 AM
Hi Andrew,
@Andrew Neil wrote:Is it possibly for you to attach a debugger to a board in this "stuck" state?
See: Best Practices for Debugging Intermittent MCU Freezes on STM32.
Good point! I'm going to try during the next stuck.
But the susceptibility of your system is under your control.
@Lucast wrote:how can I find what is the pin (or what are the pins) susceptible to the EMI?
Has your product undergone EMC (particularly susceptibility) testing ?
In particular, testing relevant to "industrial traction" environments?
Yep. It's full compliant. We replicate some reset on the MCU by using ESD gun at level beyond the level of the normative (i.e. 10-11kV instead of 8kV) but we're not sure it's the same problem because we were not able to replicate the freezing with ESD gun.
2026-01-21 8:58 AM
@Lucast wrote:we were not able to replicate the freezing with ESD gun.
So it could be just a software issue.
Take a look at the linked thread - several suggestions of things to look for there...
In particular, do a review of your Watchdog management - are there places where the watchdog could be getting updated, even though the software is "stuck" ?
2026-01-22 8:18 AM
The watchdog managements seems ok.
We've two boards in the freezing state that are coming to us (from the customers).
Could I do something to analyze the issue?
Other to confirm it's a latch-up and possibly to understand which pin(s) cause that?
Thanks
2026-01-28 4:54 PM - edited 2026-01-28 5:09 PM
2026-01-29 1:24 AM
@daniaoday wrote:while mine keeps rebooting repeatedly.
See: STM32L4 STOP2 System abnormal restart.
2026-01-29 2:41 AM
Hi daniaoday,
I think your is not an "opposite" issue, but a similar issue. Our customers have either: freezed boards and boards that resets. I think the difference is due to the different EMI level of the spike/noise, eg:
Have a look at AN1709: EMC design guide for STM8, STM32 and legacy MCUs.
2026-01-29 3:24 AM
Got it. I need to first confirm the cause of the reboot before analyzing what triggered it.
2026-01-29 3:37 AM
> Someone suggest me some latchup phenomena and I think it could be a possible explanation.
This might well be.
But usually, the mechanism for for such an issue involves a core lockup.
This happens when an unhandled exception occurs within an exception handler.
You could try to instrument you code, e.g. GPIO outputs (which you would need to watch), or some form of nonvolatile memory.
Not sure if you use a watchdog of some sorts.