2025-07-31 5:33 AM - edited 2025-07-31 5:33 AM
Hi!
Is there support for enable and view SWO output in the STM32 VScode 3.x.x. extension using ST-LINKV3?
For now, this is the only feature that would keep us from moving away from the old eclipse-based platform.
If there is no SWO support: Is it on the roadmap?
Solved! Go to Solution.
2025-08-05 12:24 AM
Hi @jostlowe,
Thanks for making this request. One of the first requests for the SWO feature... We are working on recovering the feature gap vs STM32CubeIDE (Eclipse). The SWV feature is one block of features which we have not yet allocated time for. To be realistic, I think it will take us some time to get there.
That said, you can move to VS Code as your primary edit/build environment. And use STM32CubeIDE only for debug. It might not be suitable for your existing projects since you would have to port STM32CubeIDE projects to CMake to develop with VS Code... But if you start your next project with VS Code and CMake, then you can use STM32CubeIDE debugger side-by-side. It takes you ~1 minute to setup.
I encourage you to look at chapter "Import STM32 Cortex®-M executable" in the STM32CubeIDE User guide:
https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf
Follow-up question: When using SWO, what is the primary use case you need?
2025-07-31 5:51 AM
Many years ago I got SWO working on a custom tool chain for VSCode using the cortex-debug extension. I haven't tried the ST extension in years, so I don't know if they support it directly. But there is no technical reason why it shouldn't work.
2025-07-31 6:06 AM
Thanks for the quick reply.
I got SWO to work using the cortex-debug extension a while back, but with the 3.x.x releases ST seem to have shifted away from cortex-debug (which i believe was used on the 2.x.x releases?) and towards a more proprietary platform using the STM32Cube Debug Generic GDB Server and STM32Cube Debug Core plugins.
I was curious to know the status of SWO on the new platform
2025-08-01 12:01 AM
I guess it would be sufficient to pass some values to the --swd, --swo-port, --cpu-clock, and --swo-clock-div flags when the ST-Link GDB server launches, e.g. trough the launch.json file, so that the SWO data is exposed by the GDB server on a TCP port
2025-08-05 12:24 AM
Hi @jostlowe,
Thanks for making this request. One of the first requests for the SWO feature... We are working on recovering the feature gap vs STM32CubeIDE (Eclipse). The SWV feature is one block of features which we have not yet allocated time for. To be realistic, I think it will take us some time to get there.
That said, you can move to VS Code as your primary edit/build environment. And use STM32CubeIDE only for debug. It might not be suitable for your existing projects since you would have to port STM32CubeIDE projects to CMake to develop with VS Code... But if you start your next project with VS Code and CMake, then you can use STM32CubeIDE debugger side-by-side. It takes you ~1 minute to setup.
I encourage you to look at chapter "Import STM32 Cortex®-M executable" in the STM32CubeIDE User guide:
https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf
Follow-up question: When using SWO, what is the primary use case you need?
2025-08-05 12:31 AM
Hi, Mattias, and thanks for the reply.
Looking forwards to seeing this feature and what you guys can accomplish with the shifted focus to cmake and vscode!
For SWO, we primarily need the ITM to implement printf for a logging framework.
In the meantime, using the debugger in STM32CubeIDE is a decent solution.