cancel
Showing results for 
Search instead for 
Did you mean: 

Serial terminal

ANeam.1
Associate III

Hi, I am seeking some guidance.

With the new release STM32CubeIDE for Visual Studio Code 3.8.0, it says it comes with new features including

Serial terminal: Enabling developers to easily setup serial communication for example leveraging the ST-LINK virtual com port."


In the docs, there is not much explanation on how to get this working. I only see:
"
If the serverPort attribute is defined, two ports are used by the ST-LINK GDB server: one for the debug session and serverPort + 1 for the SWO connection.

These ports are reserved even if SWO is not activated in the debug configuration."

How would one activate the SWO in the launch.json? I went through all the options with completition and none seem to activate or configure the SWO.
I know that with the extension "Cortex-Debug" provided by marus25 we could configure the SWO as so:

"swoConfig": {
                "enabled": true,
                "cpuFrequency": 275000000, // must match -a (Hz) :contentReference[oaicite:4]{index=4}
                "swoFrequency": 1375000, // 2MHz example (Hz) :contentReference[oaicite:5]{index=5}
                // This is the key: read SWO from a socket (ST-LINK_gdbserver -z)
                "source": "socket",
                "swoPort": "localhost:61235",
                "decoders": [
                    {
                        "label": "ITM Port 0 (printf)",
                        "type": "console",
                        "port": 0
                    }
                ]
            }

My actual configuration is (I am using a STM32H735G-DK board):

{
            "type": "stlinkgdbtarget",
            "request": "launch",
            "name": "STM32Cube: STM32 Launch ST-Link GDB Server",
            "origin": "snippet",
            "cwd": "${workspaceFolder}",
            "preBuild": "${command:st-stm32-ide-debug-launch.build}",
            "runEntry": "main",
            "imagesAndSymbols": [
                {
                    "imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}",
                }
            ],
            "serverExtLoader": [
                {
                    "loader": "${env:CUBE_BUNDLE_PATH}\\programmer\\2.22.0+st.1\\bin\\ExternalLoader\\MX25LM51245G_STM32H735G-DK.stldr",
                    "initialize": false
                }
            ],
            "liveWatch": {
                "enabled": true,
                "samplesPerSecond": "4"
            },
            /*"serverRtos": {
                "enabled": true,
                "port": "60000",
                "driver": "freertos"
            },*/
            "serverPort": "61234",
        },

So, if I understand correctly the docs, if we set a serverPort to 61234, it will reserve this port for ST-LINK GDB server and 61235 for SWO connection.

Any guidance on how to make this work and display the SWO strings to a terminal within VSCode?

Thank you!

1 ACCEPTED SOLUTION

Accepted Solutions
LudovicR
ST Employee

hi @ANeam.1 

 

Semihosting support inside STM32CubeIDE for Visual Studio Code is based onto rdimon library. Here is a good article on how to update your code:

How to use semihosting with STM32CubeIDE and STM32 - STMicroelectronics Community

 

Usage of SWO for printf is known in STM32CubeIDE Eclipse as "SWV ITM Data Console and printf redirection" (from User Manual, chapter 3.2.3.5). It will be supported later in STM32CubeIDE for Visual Studio Code.

 

BR,

LudovicR

View solution in original post

6 REPLIES 6
Nawres GHARBI
ST Employee

hi @ANeam.1 

Try with this tag

          "serverSemihosting": {
                "enabled": true,
                "mode": "console",
                "port": "61260"
            },
ANeam.1
Associate III

Hi @Nawres GHARBI ,

Thank you for the prompt reply.


Sorry for my ignorance, I did try with "serverSemihosting". It did indeed create a new tab called "STM32CUBE TCP CONSOLE", but when I run the debug, it does not print anything to the console. I did try with port 61235 and also 61260 as suggested, none worked. I have a bunch of printfs in my code, and I did configure the __io_putchar() to forward the char to ITM_SendChar(). The same code worked well with the STM32CubeIDE and SWO. Is this Semihosting something other than SWO? I was expecting to setup the cpuFrequency, the swoFrequency and enable the ITM ports we desire, as we always do in STM32CubeIDE?

 

Thank you!

LudovicR
ST Employee

hi @ANeam.1 

 

Semihosting support inside STM32CubeIDE for Visual Studio Code is based onto rdimon library. Here is a good article on how to update your code:

How to use semihosting with STM32CubeIDE and STM32 - STMicroelectronics Community

 

Usage of SWO for printf is known in STM32CubeIDE Eclipse as "SWV ITM Data Console and printf redirection" (from User Manual, chapter 3.2.3.5). It will be supported later in STM32CubeIDE for Visual Studio Code.

 

BR,

LudovicR

Andrew Neil
Super User

@ANeam.1 wrote:

Serial terminal: Enabling developers to easily setup serial communication for example leveraging the ST-LINK virtual com port."


The Virtual COM Port (VCP) is used with a UART on the Target MCU; not SWO - that's something different.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Hi @Andrew Neil ,

Yes, I read after my post about SemiHosting vs VCP vs SWO. It is all more clear now.

In my project I was already redirecting also the chars towards the UART. While connected to the ST-LINK I was debugging my App in VSCode and in parallel I was opening a TeraTerm connected to the VCP. This setup works, but reading the line you also commented on I was hoping to have this terminal (the TeraTerm equivalent) directly inside VSCode. Is that something we can do? If not I will stick with TeraTerm till STM32CubeIDE for Visual Studio Code extension will implement the true SWO as in CubeIDE.

Thank you!

A COM port (virtual or otherwise) can only be opened by one thing at a time;  so if you were already using it in TeraTerm, then nothing else - incliding VSCode - would be able to use it.

Personally, I find it easier to stick to using a standalone terminal rather than one integrated with the IDE.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.