STM32F407 stuck. Latchup? How to find the weakness?

[Lucast]

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!

[Andrew Neil]

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?

[Lucast]

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.

[Andrew Neil]

---

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

[Lucast]

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  

[Ozone]

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