SWO stops collecting data after a few packets

[Herm]

I'm trying to do some debugging using SWO on an STM32G474. After a very short amount of time no new packets are displayed in CubeIDE (usually after ~2500 packets). I limited the SWO frequency to various values between 100kHz and 8 MHz. Using an oscilloscope I can verify that the data is still being output at the correct rate by the MCU but no data is received by either the STLink probe or CubeIDE.

I tried many combinations of settings (shared STLink, OpenOCD instead of ST-Link GDB server, reset mode, low power debug mode [I don't use low power modes], baudrate, etc.) and nothing worked.

CubeIDE version 1.14.0.

Debug log:

STMicroelectronics ST-LINK GDB server. Version 7.5.0
Copyright (c) 2023, STMicroelectronics. All rights reserved.

Starting server with the following options:
 Persistent Mode : Disabled
 Logging Level : 1
 Listen Port Number : 61234
 Status Refresh Delay : 15s
 Verbose Mode : Disabled
 SWD Debug : Enabled

Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
 -------------------------------------------------------------------
 STM32CubeProgrammer v2.15.0 
 -------------------------------------------------------------------



Log output file: C:\Users\HERMAN~1\AppData\Local\Temp\STM32CubeProgrammer_a30704.log
ST-Link Server is running on port : 7184
ST-LINK SN : 001E001A3756501220303658
ST-LINK FW : V3J13M4B5S1
Board : STLINK-V3MODS
Voltage : 3.26V
SWD freq : 8000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x469
Revision ID : Rev Y
Device name : STM32G47x/G48x
Flash size : 512 KBytes
Device type : MCU
Device CPU : Cortex-M4
BL Version : 0xD4
Debug in Low Power mode enabled



Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a30704.srec
 File : ST-LINK_GDB_server_a30704.srec
 Size : 123.54 KB 
 Address : 0x08008000 


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [8 38]
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:02.383



Verifying ...




Download verified successfully 

 

[AScha.3]

Maybe the buffer (in IDE) is full.  But it should give you a message about this.

 

Try : making bigger ;  in window -> preferences -> 

 

[Herm]

Thank you for your suggestion. I increased it tenfold but the effect is the same. After ~2500 packets the trace stops.

[Pavel A.]

Please try using the CubeProgrammer (GUI or CLI), it has SWO output mode.

 

[Herm]

Cube Programmer doesn't seem to have an option for data trace, but that's the function I need. 

[Pavel A.]

 

[Herm]

Sorry for my late reply. I had to work on other projects for some time. 

As far as I can see this function is only for printf-style debugging. I need data trace debugging where I record every change of a certain memory location without modifying my code.

[Pavel A.]

> As far as I can see this function is only for printf-style debugging

> I need data trace debugging where I record every change of a certain memory location 

ITM_PrintChar is the "API" usually intended for printf.  But ITM (the thing behind the SWO line) can do much more than a simple printf. Look at the ITM configuration dialog and read some ARM documentation to get a clue. Yes, it can be used for data watchpoints. 

 

[andershedberg]

I have the same problem. I need to restart the debugging session for it to get going again. Any updates on this? It's useless right now.
---
Pavel A's suggestion of using the Serial Wire Viewer in the STM32CubeProgrammer do work(!) and I can see both the characters nad the printf data numbe increase. Very strange, but it seems the STM32Cube has some errors regarding SWO output.

[tjaekel]

SWO viewer works fine for me since years.

When it could fails (after number of packets) - my guesses:

• your code (FW) crashes
• you reconfigure the system clock (a different core clock now)
• maybe: you send too often (and too fast, in terms of repetitions - the SWO goes via "slow" speed debug infrastructure and via single serial wire, you "overflow" the DAP, debug)
• something in your code disables the SWO (inside MCU)
• you use the SWO pin for something else (e.g. a GPIO or a peripheral device signal)
• you slow down the MCU (clock config) or you change the voltage range (entering low power mode)

 

[andershedberg]

There are several problems. I use the ST-Link V3Mini-e, and if I use the USB on the back of the computer, it simply stops after ~1000 frames. If I use the USB ports on the front, it just continues to stream. This is on Debian and the STM32CubeProgrammer. This is when i use a small STM32 controller.

There are also known issues with the STM32H723/33 that I am using and getting SWO to work. Several threads on this forum about it... I've now ordered a plain disco board and a Segger debugger that uses ethernet intstead of USB to see if this sorts out some of the strange things. 

[Pavel A.]

>  if I use the USB on the back of the computer, it simply stops after ~1000 frames. If I use the USB ports on the front, it just continues to stream.

:thinking_face:

[Herm]

Today I upgraded to STM32CubeIDE 1.15.0 and performed the STLink upgrade that came with it. Now SWO works again.