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.

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

[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!

[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?

[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:

[Andrew Neil]

You still haven't given hardware details:

• Schematics
• Layout
• Operating environment; eg, are there motors or other noisy things, heavy loads, etc  about...
• What is the function of this board
• Some good, clear photos of the setup

Again, please see: How to write your question to maximize your chances to find a solution

---

@robert3 wrote:

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

---

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

---

@robert3 wrote:

Power supply check: Measured with a multimeter and stable at 3.3V during operation.!

---

A multimeter won't show you brief glitches, brownouts, etc - you need a scope or power analyser; eg, ST has:

• STLINK-V3PWR

• X-NUCLEO-LPM01A

other manufacturers are available

What is your power source? 

---

@robert3 wrote:

Watchdog: Configured to reset every 500ms, but it doesn’t trigger during the freeze, likely because the code hangs before the watchdog gets updated.

---

So how are you doing the update?

The whole point of a watchdog is to catch this type of issue - so the update must be done with that in mind...

You're not updating in an interrupt, are you?

---

@robert3 wrote:

• Tried attaching debugger during runtime, but freeze happens sporadically

---

As noted previously, you can connect the debugger to the system once it is in the "frozen" state.

Then you can see where, exactly, it is stuck - which should give you clues to how it got there, and why the watchdog isn't triggering.

---

@robert3 wrote:

There’s no hard fault

---

How do you know that?

[Ozone]

> No static analysis done yet plan to check for infinite loops as you suggested

This is not an issue of static analysis.
The toolchains use to provide templates for all interrupt and fault handlers, usually in a file stm32xxx_it.c.
I'm not a Cube user, don't know if they still use this naming scheme.

Anyway, I suspect you end up in a hardfault, after some illegal access.
The implementation the ST firmware packages provided used to look like this :

void HardFault_Handler(void)
{
  while (1);  /* Go to infinite loop when Hard Fault exception occurs */
}

I think you need to invest the time, and run the application in the debugger to find out the cause.
Once stopped, you can investigate further.

A hardware issue, like a supply or clock instability, usually manifests either in the first milliseconds, or the first 15 minutes until the board reaches thermal equilibrum. Which is not the case here.