I am using SWV as my trace output on STM32F4 (STM32F437VG on a custom board and STM32F407 on a Discovery board). I need to be able to capture this output using command-line tools and into a text file or similar (on Windows 10) so that I can use it in my CI system. However I cannot get ST-LINK_gdbserver.exe to give me SWV output all of the time. Here are the data points:
- This works 100% of the time on one machine, 10% of the time on the other. Both are Windows 10 under the same IT infrastructure with the same version of ST tools installed (1.3.0, ST-LINK_gdbserver.exe version 5.5.0) and the same version of the ST-Link debug driver (2.1.0.0).
- On the machine where it only works 10% of the time capturing SWV output with the ST-Link tool or from within the STM32Cube IDE works 100% reliably with the same settings (system clock 168000000, SWV frequency 2000 kHz) and the reported target voltage is fine (3.23 V), so I do not believe there is a HW issue. However these tools are no use to me as I need a CLI interface and the output to be machine readable, not in a GUI.
- This is the command-line I am using:
ST-LINK_gdbserver.exe -d -a 168000000 -b 84 -p 61200 -z 61300
- The commands at the GDB client end (arm-none-eabi-gdb.exe from the same ST tools, version 8.1.0.20180315-git) are:
target remote localhost:61200
monitor reset
continue
- I have tried changing the SWV output speed to be lower than 2 MHz and the port number to be something other than 61300 but this makes no difference.
- In all cases the code download process and GDB client connectivity to the target via ST-LINK_gdbserver.exe is 100% reliable so I don't believe there is a general USB issue. The problem lies solely with SWV trace output from ST-LINK_gdbserver.exe.
- ST-Link_gdbserver.exe is aware I am monitoring port 61300 as it prints "Accepted connection on port 61300" when I connect and, if I disconnect while it is meant to be running, ST-Link_gdbserver.exe complains "SWV info, Socket error!!!".
- In all cases ST-LINK_gdbserver.exe prints "SWV_SetStatus(true): stop_reply_pending == 0", "TraceCaptureStart and SWV event set to APP_TRUE" when a run begins.
- When it bursts into life and works, it works absolutely fine for a few runs in a row but then goes back to doing absolutely nothing again. Black and white.
- Clutching at straws I've tried different USB ports; doesn't make a difference.
Has anyone else seen issues of this nature, or can anyone suggest something else I could try? FYI I've tried using Open OCD but unfortunately that doesn't work in a different way (though SWV logging always starts reliably Open OCD fails to output the end of the trace buffer 50% of the time).
