How to safely debug critical circuits

[Tobe]

Hi,

i believe i have blown up some IC`s while debugging. Its a BLDC driver.

Now i wonder how i safely could debug it. I know of the intrusive nature of debugging, but not that well.

Does anyone know a good article, or can provide some knowledge? Especially i wonder, is the debugger always stopping at the exact spot? How would implement a safe debugging breakpoint, while other things like PWM has to be controlled, in order to not let current go beyond specs?

[Andrew Neil]

Check the Reference Manual for your chip - there may be options to control what happens when the CPU is halted by the debugger:

https://community.st.com/t5/stm32cubeprogrammer-mcus/hard-fault-that-happens-only-with-debug-and-using-pause-start/m-p/764245/highlight/true#M7738

---

@Tobe wrote:

I know of the intrusive nature of debugging, but not that well.

---

The key thing is to avoid halting debug - breakpoints, stepping, manual halt/resume - unless the system is in a "safe" state.

Some tips:

https://community.st.com/t5/stm32cubeprogrammer-mcus/hard-fault-that-happens-only-with-debug-and-using-pause-start/m-p/764266/highlight/true#M7744

In addition:

• Collect "trace" or "log" data in a memory buffer, for later examination
• Use hardware pins to provide status output; eg, simple indications to LEDs, or more complex to a logic analyser
• Realtime monitoring of currents & voltages; eg, on oscilloscope
• etc

PS:

You might look into Segger's Monitor mode debugging:

https://www.segger.com/products/debug-probes/j-link/technology/monitor-mode-debugging/

[Ozone]

I think the key is to understand the difference - "debugging" in a sense of only observing the actual behavior.

As already mentioned, GPIOs (and status signal outputs using these GPIOs) are a great help in this situation, as they have very little impact on realtime behavior.
I occasionally had to use this method as the only one available, as my employer at that time thought omitting a debug interface is a cost-saving measure.

And you can use GPIO outputs in conjunction with a scope, e.g. use it as a trigger for a single-shot scope capture.

[unsigned_char_array]

A debugger can influence the CPU, especially when halted. You can use the SWO pin to export variables (live expressions) or print messages to the debugger console real-time.
If you want to avoid any influence of the debugger you can use GPIO-pins. If you have spare GPIO-pins you can output the state of your code to the GPIO-pins and use a logic analyzer to analyze the behavior of your code w.r.t. inputs and outputs in real-time.