Methods of debugging when MCU operations require real-time operaton

[OIp.1]

Hi. I am testing some USB_FS communication between my PC and my STM32 board (specifically STM32756-EVAL). I am wondering what the most appropriate and standard debugging methods in STM32 are, in situations where the debugger cannot be used.

The reason I ask is because I had a previous post asking about USB_FS, where I was told that

> USB device operation requires real-time response. Debugger is intrusive, it causes the device to lose connection with host.

Hence, I am searching for the standard method of debugging without the STM32 debugger. So far I using a blinking LED as a signal for "where the code is" but other than that, nothing at the moment. Thanks.

[S.Ma]

In the EVAL board, you may use third party debug probe which provides extra debug features such as MIPI-20 connector with 4 bit traces.

Otherwise, you can use live watch debug window to see buffers or global variables on the fly (stealing few cycles as the DMA does).

For non real time debug, printf on a USART connected to the STLink for a teraterm "printf" like debug.

Motor control is similar: a breakpoint can break things...

[KnarfB]

besides that:

You may set aside a SRAM buffer and redirect printf (or a more lightweight logging) to that buffer.

Here is some legacy code (FreeRTOS use not mandatory): https://gitlab.com/KnarfB/timedoctor

A cheap logic analyzer connected to few IOs may do better than a LED.

USB or network: Wireshark packet tracing on the other side.

see also AN4989 Application note "STM32 microcontroller debug toolbox"

hth

KnarfB

[Wall-E]

Hello,

The simplest method is to instrument the code by printing messages to a UART using printf(). On the STM32H757I-EVAL board, UART1 is connected to the STLink and automatically enumerates as a virtual com port on the host PC when you connect to the ST-Link USB connector (CN23). If you have a different board, please check the user manual to know which UART to use.

You can also print to the ITM which sends them to the SWO (serial wire output) port. Most IDEs can receive and display messages without having to halt the code execution.

For more information please check out AN4989 : https://www.st.com/resource/en/application_note/an4989-stm32-microcontroller-debug-toolbox-stmicroelectronics.pdf

The above solutions are invasive, in that you need to modify the source code to embed the printf() statements. Fully non-invasive debugging is also available using the built-in CoreSight trace components, which allow code execution to be logged via the trace port interface. However this requires additional hardware such as a trace probe to capture the trace stream and a trace port analyser to decode it.

Hope this helps, feel free to come back if you have more questions.

[Tesla DeLorean]

Telemetry, Diagnostic information and Dynamic Flow can be reflected via UART or SWV communication channels.

Buffering data to slower UARTs can help in speed/response critical code, but you have to watch overall bandwidth/volume of data being generated. Often helps to be able to be selective, or control level/scope of messages, or character output.

Some kind of interactive monitor/terminal also allows for less intrusive control and query. This can also help for field debugging where there is no need to have a debug pod attached.

Most of the cores allow for Trace information, which can be useful for particularly difficult situations.

Output actionable information from HardFault_Handler() and Error_Handler() so those can be use for support.

Use assert() to catch parameter level issues.

If your device has a screen, you can perhaps output diagnostic information via that.

[waclawek.jan]

Whatever is debugging method on mcu side, for USB work I recommend to have a means to observe the USB bus. There are USB analyzers (devices) out there, but also some LA/oscilloscopes can do USB bus analysis, maybe requiring a plugin.

JW