Windows command line tool for SWD viewing

[Rob Meades]

Stupid newbie question: apologies if I've missed this but I'm looking for a Windows command-line tool to capture SWO output from the target, i.e one that connects to the target, sets the appropriate register bits to configure SWO output etc., takes a configuration item for a frequency value and then streams the SWO line output from the target to stdout or a named file.

To be clear, I don't want a GUI tool, this is for running under automation where there is no GUI possibility, I just need my debug printf()s sent to a file. I know the ST-LINK utility can do it in GUI form but the command-line version doesn't seem to be able to do the viewing part.

Thanks in advance for your help.

[Rob Meades]

I take it there's no such thing? Strange, it seems like an awfully basic tool to be missing.

[Uwe Bonnes]

Have a look at orbuculum https://github.com/orbcode/orbuculum

[Rob Meades]

Oooo, it says "orbdump: A utility for dumping raw SWO data to a sfile for post-processing." Looks like just what I need! Thanks very much indeed for pointing this out.

[Rob Meades]

Finally got around to looking at this and, unfortunately, orbuculum's Makefile requires Cygwin to build on Windows and depends on a selection of libraries some of which I can't find in the Cygwin list. Anyone have any other ideas? Is there no simple Windows .exe out there? It can't be this difficult...?

[Rob Meades]

Digging deep, I can run:

ST-LINK_gdbserver -d -v --swo-viewer 61235 -a 168000000 -b 84

...which matches what STM32Cube configures, and then I can connect to it on port 61235 with PuTTY. However, though I can reset and run the target with a GDB client connected to 61234, and the GDB server says helpful-sounding things like:

SWV_SetStatus(true): stop_reply_pending == 0

TraceCaptureStart and SWV event set to APP_TRUE

...I never get any SWO output in PuTTY. So I'm missing a configuration step somewhere. Advice welcomed.

To be clear, this all works fine in the STM32Cube IDE, so I know my target code is behaving, it's getting stuff out in a continuous-integration-compatible way that is the problem.

[Rob Meades · Accepted solution]

FYI, for anyone else that finds this, the answer was that, buried in the STM32Cube IDE installation folders, is a copy of OpenOCD plus configuration files for all the ST chips, so all one has to do is:

openocd –f stlink.cfg –f stm32f4.cfg -c init -c "itm port 0 on" -c "tpiu config internal temp.dat uart off 168000000 2000000" -c "reset init" -c resume

…to pipe the ITM output to a file named temp.dat and then run this Python script, modified slightly to assume it has sync from the outset (sync bytes don't seem to appear in the stream) and Bob's your sister's brother, so to speak.