Best Practices for Debugging Intermittent MCU Freezes on STM32

[robert3]

Hi everyone,

I am working on an STM32-based project and occasionally facing an issue where the MCU freezes during normal operation. There’s no hard fault or obvious error, and the issue doesn’t happen consistently, which makes it harder to trace.

So far, I have checked:

Stack and heap usage

Watchdog configuration

Power supply stability

Basic clock and reset settings

The project runs fine most of the time, but under certain conditions (long uptime or repeated operations), it becomes unresponsive and requires a reset.

I wanted to ask the community:

What are your go-to steps for debugging intermittent freezes on STM32?

Are there specific STM32 tools or registers you usually monitor for this?

Any common pitfalls you’ve seen related to low-power modes, interrupts, or RTOS usage?

I’m mainly looking for practical debugging tips or real-world experiences that could help narrow this down.

Thanks in advance for your help.

[mƎALLEm]

Hello @robert3 and welcome to the ST community

No direct answer to your request as the question is vague. 

What do you mean by "MCU Freezes" how did you debug it? describe the symptom in details.. 

1- What STM32 part number are you using?

2- What board are you using? share an image of it.

3- What IDE are you using?

The issue could be either hardware or software. You said "I have checked: Power supply stability" how do you know it's stable? it could be also an issue due to a bad Flash wait state value, it could be a bad clock config, bad decoupling capacitors etc .. not possible to help at this stage.

 

[robert3]

Thanks for your reply! Here are more details:

• STM32 part number: STM32F407VG

• Board: Custom PCB

• IDE: STM32CubeIDE

• Symptoms: MCU sometimes stops responding, no serial output or LED activity  until a reset. Happens after several hours or repeated tasks.

• Debug steps so far: Checked power supply, stack/heap usage, clock config, and basic resets. Running in debugger is tricky since freeze is sporadic.

Any tips on how to catch these intermittent freezes or what to monitor would be really helpful.

Thanks!

[AScha.3]

>Symptoms: MCU sometimes stops responding

1. might be a hardware problem (spike coming in, maybe even on ground connection) , 

or your software doing something "legal" (= no hard fault generated), like (what i already produced) looping in an INT waiting for a signal...that never comes (or was just a ns spike, triggering the INT ).

2. besides the tips you got....you can connect in CubeProgrammer to the "stuck" cpu without reset:

..in hot plug mode. Just to see: where it is and is it still running/working;

so you can come closer to find out: hardware spike puzzling the core or just hanging in an INT.

here on H743:

RUN lets it just run on - where it was executing....whatever. :)

And checking for hard fault:

 

[Ozone]

You might need to provide a bit more information about the issue.

First, what exactly do you mean with "freeze", and what are the characteristics ?
In contrast to e.g. a hardfault.

Second, do you talk about a commercially available board (e.g. Nucleo), or a custom board ?

> The project runs fine most of the time, but under certain conditions (long uptime or repeated operations), it becomes unresponsive and requires a reset.

This sounds like an unhandled exception, either an interrupt, or a fault handler.
Especially the latter have "weak" default implements, usually as "while(1) {}" loops.

I would try to start the application in the debugger, and wait until it "becomes unresponsive". When stopping code execution, it should point you to the respective location.

[Andrew Neil]

Welcome to the forum.

For best results, please see How to write your question to maximize your chances to find a solution

In particular, you haven't given any details of your hardware, or the environment in which it works.

 

As @Ozone suggests, the first thing is to find what, exactly, is happening in this "freeze" condition.

Have you done a static analysis of your source code to search for any potential infinite loops?

You can connect to a running (or "frozen") target in CubeIDE without doing a reset or download:

https://community.st.com/t5/stm32-mcus-embedded-software/processor-stuck-if-i-run-code-without-debugger/m-p/802267/highlight/true#M63401

https://community.st.com/t5/stm32-mcus-boards-and-hardware/connecting-to-running-target/m-p/272666#M9437

 

---

@robert3 wrote:

So far, I have checked ... Power supply stability.

---

How, exactly, did you check that?

 

---

@robert3 wrote:

Watchdog configuration.

---

What, exactly, do you mean by that?

The purpose of a Watchdog should be escape from any "hangs" or "freezes" - so are you saying that you have a watchdog configured, but it's not "catching" the hang?

That would suggest a poor update strategy for the watchdog.

 

---

@robert3 wrote:

What are your go-to steps for debugging intermittent freezes on STM32?.

---

Nothing specific to STM32 - any microcontroller can "hang" or "freeze"!

A key one is to instrument your code - so you can see what's happening while it's running.

Common techniques include:

• output to a serial port
• Trace, if your microcontroller supports it
• logging to a memory buffer
• LEDs or other display
• GPIO pins to view on a scope or logic analyser

---

@robert3 wrote:

Any common pitfalls you’ve seen related to low-power modes, interrupts, or RTOS usage?.

---

Are you using an RTOS, then?

If so, check out what features it has to help with debugging/diagnostics.

 

---

@robert3 wrote:

I’m mainly looking for practical debugging tips or real-world experiences that could help narrow this down.

---

Here you go:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/tac-p/706966/highlight/true#M49

 

PS:

---

@robert3 wrote:

The project runs fine most of the time, but under certain conditions (long uptime or repeated operations), it becomes unresponsive and requires a reset.

---

You could focus on those "repeated operation" - find a sequence which reliably provokes the "freeze" ...

[robert3]

Thanks for your detailed guidance and links! Here’s more information about my setup and what I have done so far:

• STM32 Part Number: STM32F407VG
• Board: Custom PCB
• IDE: STM32CubeIDE
• RTOS: None (bare-metal setup)

Symptoms: MCU sometimes becomes unresponsive, no serial output or LED activity, after long uptime or repeated tasks.

Power supply check: Measured with a multimeter and stable at 3.3V during operation.
Watchdog: Configured to reset every 500ms, but it doesn’t trigger during the freeze, likely because the code hangs before the watchdog gets updated.

Debugging attempts:

• Checked stack/heap usage
• Verified clock and reset configurations
• Tried attaching debugger during runtime, but freeze happens sporadically
• No static analysis done yet plan to check for infinite loops as you suggested

I will try code instrumentation (serial output, GPIO toggling) next to narrow down the freeze. Any additional tips for catching intermittent freezes reliably would be greatly appreciated.

Thanks again!

[mƎALLEm]

Hello,

1- Please share screen shots of the problem especially when you pause the program execution.

2- Share your schematics.

3- Are you using an RTOS? if yes, did you try to run a very simple example without RTOS at least to check the hardware is fine?

 

[unsigned_char_array]

Double check stack usage. Note that total stack usage can exceed what the compiler thinks it is. If you enable an interrupt you need to add the stack usage of that interrupt to your worst case stack usage of function calls from main/threads. If you enable nested interrupts you can get 2 interrupts at the worst possible moment and need to add both of them to your worst case stack usage. You can calculate stack usage or measure it by putting a known pattern in memory.

Another common problem is hardfault. I recommend turning on an LED in the hardfault handler.

Infitite loops were mentioned before.

 

uninitialized stack variables can cause problems that only show up after a long time. Their value depends on what happens to be on the stack at that moment.

You checked the power supply voltage, but you didn't check it at the time of the crash I presume. So there could still be a dip. I recommend enabling the brown out detector.

If you enable a watchdog timer you will automatically reset if your program freezes.

At boot you can check the reset cause. So if program resets due to watchdog or brown out you can show that.

 

Improper DMA usage can corrupt your memory and cause unexpected behavior of your program.

[Andrew Neil]

---

@unsigned_char_array wrote:

If you enable a watchdog timer you will automatically reset if your program freezes.

---

Unless you do something silly like updating the watchdog in a timer interrupt ...

[Andrew Neil]

@robert3 is this a new project, or something old & established which has just recently started showing this behaviour?

Or even something old & established which has always done this, and is only now being investigated?

Great thread on best practices for handling intermittent MCU freezes — the practical troubleshooting tips and methods for narrowing down issues are really helpful. When working with embedded systems, having clear diagnostic feedback makes all the difference in solving tough bugs. That focus on visibility and tracking mirrors what’s valuable in other workflows too — whether it’s code behavior or delivery status, knowing exactly what’s happening helps you act faster and more confidently. Thanks for sharing these insights!

[Andrew Neil]

@robert3 You've marked a solution, but you haven't said what the actual problem was.

To better Help others to solve their issues, could you say what you found?

 

eg, today someone else has a similar situation: STM32F407 stuck. Latchup? How to find the weakness?

[robert3]

Thanks for the clarification.

You are correct I marked that reply as a solution too early. It was helpful from a debugging perspective, but the root cause has not been fully identified yet. I’ve unmarked it and will update the thread once I have a confirmed cause and resolution.

Appreciate the reminder and the community’s guidance.