What Is the Most Useful Debugging Technique You've Learned for STM32 Projects?

[Johnsmiteo]

I'm interested in improving my debugging workflow when working with STM32-based projects. Beyond using breakpoints and serial output, what techniques or tools have made the biggest difference for you?

Do you rely on STM32CubeIDE features, hardware debugging tools, logic analysers, or custom testing methods? Are there any common mistakes beginners should avoid when troubleshooting timing issues, peripheral configurations, or communication protocols?

I'd love to hear about the debugging practices that have saved you the most time in real-world projects.

[Andrew Neil]

Not really specific to STM32 - these techniques are pretty general.

 

The most important tool is the one between your ears, and using it to analyse the problem, think critically, etc.

 

More tips on How To Debug.

[David Littell]

Coming from a hard real-time background I’ve come to require a hardware design to provide some number (4 works well for my efforts) of dedicated GPIO outputs routed to a 0.1” pin header that I use both for timing instrumentation/telemetry and general debugging.  These are used with a Saleae to monitor the timing telemetry (usually assigned to 2 of the GPIO’s) and general debugging.  The support code for the GPIO’s allows setting a specific level, toggling, and pulsing so I have a toolbox to fabricate a “mental protocol” of the GPIO behavior depending on the need.

A dedicated GPIO input is occasionally very useful - that gets its own 2-pin header so I can just drop in a jumper when needed.

Some hardware guys piss and moan about having to provide these in their designs but after a few dozen broken tack-on wires (and they always break) they figure it out that my approach ultimately saves everyone lots of time over the duration of the project.

I also prefer to have two UARTs, one for any CLI that might be supported and one dedicated to debug tracing output (including time stamping).

[Andrew Neil]

Yes, Design For Debug is important!

 

Another common mistake is to look only to the software - but equally important is to look at the hardware and what’s happening outside the microcontroller.

Being able to use multimeters, oscilloscopes, and logic analysers is key.

[Pavel A.]

Why do you ask? writing a book, maybe? ;)