cancel
Showing results for 
Search instead for 
Did you mean: 

SWO stops collecting data after a few packets

Herm
Associate III

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 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Herm
Associate III

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

View solution in original post

13 REPLIES 13
AScha.3
Chief III

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

 

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

AScha3_0-1705336340145.png

 

If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Evangelist III

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

 

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

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

Pavel A.
Evangelist III

PavelA_0-1705546096854.png

 

andershedberg
Associate

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.

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)

 

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.
Evangelist III

 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: