SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

SWO ITM printf() output using ST-LINK utility while debugging

I have been able to get printf() to output via SWO by following the information in this post:


I did not change the linker flags, nor did I add the “arm semihosting enable” options to the start script.

Additionally, I made no changes to the syscalls.c file. Instead, I created my own _ _io_putchar() routine in my main.c file as follows:

  1. include // printf()

int __io_putchar(int ch) {
ITM_SendChar( ch );
return ( ch );

If I download the code and run it, I can use the ST-LINK utility “Print via SWO viewer” option and see my printf() calls executing. So all this is great so far.

What I can’t do, however, is see the output while I am single-stepping through the code. If the debugger is running (via the ST-LINK_V2 interface), the ST-LINK utility can’t find the ST-LINK_V2 adapter. If I start the ST-LINK utility before I start to debug the code, the debugger won’t start, eventually giving me the error message:

“Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333

Error message from debugger back end:
localhost:3333: The system tried to join a drive to a directory on a joined drive.
localhost:3333: The system tried to join a drive to a directory on a joined drive.”

What am I doing wrong? I assumed it would be possible to use the ITM printf() method while debugging.

Your assistance is greatly appreciated.



I don’t see you did anything wrong, but I can understand the result that you get.
The problem is that the driver of ST-LINK v2 does not designed for sharing by application
simultaneously. While you start debugging, the debugger app acquired the driver of ST-LINK v2 and the
app of ST utility can’t get the driver any more, and vice versa.

Bluenow is right. Only one tool connected at a time.
- About SWO viewer, it is a way to get traces without running a debugger. Could be useful in production;
- To get the printf traces in the OpenOCD tab, you can activate the semihosting. Note that you have to pause the debug session to get updated data values;

you can ask openocd to save itm trace to a file but you may not be abble to view trace live
it seam using a named pipe as the file is not working under window
what is a way to work aorund it openocd/debug and get race frol usb and provdie it live to the file (pipe)

semi-hosting printf can do but not ideal and very slow (semi host config required to have debuger conected to work)


Thanks, everyone, for helping me understand what is going on here.

I’m also disappointed. I like to see the debug messages while I debug my program. Is that such a strange wish?

My current workaround is: Output debug messages on a serial port and use a second cable to the PC to display them in a terminal program.

May be this can help a bit: ((https://github.com/rokath/trice |https://github.com/rokath/trice ))
If you try the RTTD variant, on a debug step over a TRICE macro you see immediately the output.

Please check if SWD is enabled in the STMcube. I got the same error that I could not debug. It is fixed by enabling it in the STM cube.

In the meantime (long ago) I figured out that openOCD can write trace messages into a text file. Append the following lines to the user defined debugger script:

tpiu config internal /path/to/debug.txt uart off 8000000
itm port 0 on