About capturing with SerialWireViewer in a openOCD

[u1kano]

I am developing software using STM32CubeIDE on Windows.

I configured OpenOCD as the DebugProbe in the DebugConfiguration and ran the Debug process
Debug Configuration > STM32 C/C++ Application > BuildName > Debugger
DebugProbe -> ST-LINK (OpenOCD)
Serial Wire Viewer -> Enable: On

When capturing with SerialWireViewer during debug execution, the program ends unexpectedly, causing the results of the Google tests running within the firmware to be interrupted.

　attached file: ConsoleErrorMessage.txt 

image_error

The Debug process and capture works correctly when the DebugProbe is set to ST-LINK GDB server.

[ST-LINK GDB server Command Line]
<InstallFolder>\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.500.202301161003\tools\bin\ST-LINK_gdbserver.exe -p 61234 -l 1 -d -z 61235 -s -cp <InstallFolder>\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.600.202301161003\tools\bin -m 0 -k

[openOCD Command Line]
<InstallFolder>\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.2.300.202301161003\tools\bin\openocd.exe "-f" "camera.cfg" "-s" "<FirmwareFolder>" "-s" "<InstallFolder>/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.0.600.202303311036/resources/openocd/st_scripts" "-s" "C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.0.500.202301161420/resources/openocd/st_scripts" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444"

I am using the default cfg file without any changes.

SWV ITM Data Console

If you have any idea to do that, that would be very nice to me. Thanks in advance.

My environmental information is as follows:
CubeIDE(Windows11) - ST-Link/v2 - device
STM32CubeIDE:Version: 1.12.1 Build: 16088_20230420_1057 (UTC)
ST-LINK FW: V2J41S7
Device: STM32H7Ax/7Bx

[Rim LANDOLSI]

Hello @u1kano ,

After analysing the error message, there is a problem with the connection between your debugger and the target microcontroller.
So, you can try these tips:
- Make sure the debugger is properly connected to the STM32 microcontroller.
- Make sure the target board is properly powered.
- Update the debugger firmware
- Configure the debug settings in STM32CubeIDE correctly by setting the correct device serial number and clock speed for the SWV

Hope this helps!

Thanks,

Rim.

[Andrew Neil]

Does your application put the processor to sleep, and/or reconfigure the debug pins ?

[u1kano]

@Rim LANDOLSI  @Andrew Neil 

Thank you for your reply.

I have an additional question.
The Google Test running within the firmware has over 200 test cases. Is it possible that the issue might be caused by insufficient SWV buffer?

> - Make sure the debugger is properly connected to the STM32 microcontroller.
> - Make sure the target board is properly powered.
> - Update the debugger firmware

The debugger and the STM32 microcontroller are properly connected and securely attached.
Power is supplied to the target.
The debugger firmware is up to date.

> Does your application put the processor to sleep, and/or reconfigure the debug pins ?
I have not performed such settings and operations.

[BarryWhit]

> The Debug process and capture works correctly when the DebugProbe is set to ST-LINK GDB server.

Why then are you asking about seeing the same hanging behavior with GDB in this parallel thread?

[u1kano]

@BarryWhit 
I am asking about the following issue in this thread:
When selecting the ST-LINK GDB Server as the DebugProbe in the DebugConfiguration of CubeIDE (GUI) and then performing Run > Debug, it works correctly and captures SWO output. However, when running the ST-LINK GDB Server from the command line and capturing SWO with STM32CubeProgrammer, it results in a hang.