cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F407 stuck. Latchup? How to find the weakness?

Lucast
Associate II

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!

10 REPLIES 10
Andrew Neil
Super User

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?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

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.


@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" ?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
Lucast
Associate II

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?

  1. For sure I'm going to connect an STLINK to try to perform debug as suggested in the linked thread.

Other to confirm it's a latch-up and possibly to understand which pin(s) cause that?

Thanks  

Hi Lucast,
Have you found any new clues or solutions? I’m running into the exact opposite issue—your device hangs, while mine keeps rebooting repeatedly.
Looking forward to your reply!

@daniaoday wrote:
while mine keeps rebooting repeatedly.

See: STM32L4 STOP2 System abnormal restart.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

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:

  • more severe spike --> latchup
  • light spikes --> reset

Have a look at AN1709:  EMC design guide for STM8, STM32 and legacy MCUs.

Got it. I need to first confirm the cause of the reboot before analyzing what triggered it.

Ozone
Principal III

> 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.