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.

[Tesla DeLorean]

Dead-Stopping large spinning masses is usually a very bad idea.

You should be beyond single-stepping your own code to know how it works and responds.

Have dynamic output of diagnostic / debugging / telemetry data, so you can understand the internal situation in real time. Have inputs into that allowing you to test modes / methods, with the ability to stop safely, or change to modes better tested.

Perhaps do super critical stuff in a separate MCU that can operate independently of other features / functions that you're in the process of developing and testing.

Have an emergency stop option that can get the system into a safe state as quickly as possible without causing physical/mechanical damage.

The STM32's often have ways of stopping timers, or letting them free-wheel. TIM+DMA can operate independently of the MCU, whereas if you're actively modifying things in IRQs, locking up the MCU is less desirable.

Perhaps wrap your breakpoints, so you monitor things in code, and can wait until a timer stops, or is as a particular phase prior to calling a breakpoint / BKPT

Again the use of a interactive monitor mode could allow you to safely observe or request behaviour. The stock debugger is going to have about zero awareness of what's critical in your system or what variables and peripherals are important.