Support for SWO in the 3.x.x VScode extension?

[jostlowe]

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?

[unsigned_char_array]

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.

[jostlowe]

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

 

 

 

[jostlowe]

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

 

[mattias norlander]

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?

• Data tracing?
• Exception/interrupt tracing?
• Statistical profiling?
• ITM Printf tracing?
• ...?

[jostlowe]

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. 

[cyclopscoder]

I just spent hours trying to get printf logging to work via SWO on the new VS Code extension (v3.x), only to discover here that this feature isn’t supported yet.

This is a really useful tool for debugging, and not having it in VS Code makes things much more challenging. It feels like a key piece of the puzzle is missing.

I hope the ST Team can prioritize adding this feature. It would be a huge help to many VS Code users.

Thanks!

[CSharpino]

Is there any news on using SWO VSCode with STM32CubeIDE V3 now that it's out of preview?
If there's no support yet, are there any issues using it the "old mode" way, using the cortex-debug extension in parallel with STM32CubeIDE V3?

[unsigned_char_array]

---

@CSharpino wrote:

Is there any news on using SWO VSCode with STM32CubeIDE V3 now that it's out of preview?
If there's no support yet, are there any issues using it the "old mode" way, using the cortex-debug extension in parallel with STM32CubeIDE V3?

---

I recommend using vscode profiles: https://code.visualstudio.com/docs/configure/profiles
Switch to a profile which doesn't have the STM32Cube plugin and you should be good. You do need to setup your own launch file though.