Problem with GDB Server on the console

[robokamran]

I get this error Waiting for gdb server to start... on the console when I use stm32-for-vscode extension. Everything works fine (compile, program, etc.), aside that Cortex-Debug always is waiting for some unknown to me GDB server to start!

I've created an issue in stm32-for-vscode but it seems that the problem is with Cortex-Debug. Please refer to this issue there which has the full problem definition as well as the possible solution suggested by @jortbmd.

[haneefdm]

Thank you for reporting this. Are you using Version 0.4.4? A change happened between 0.4.3 and 0.4.4 and wondering if it caused a regression. A couple of questions

• Does it happen all the time or just sometimes. This tab is created on the first debug session and is re-used. It will be re-started if you forcefully quit.
• If you can roll back the extension to 0.4.3 and see if it happens. Here is how to do it

Could I have your launch.json so I can see what is going on?

FYI: The reason we are moving to the Terminal Tab is to allow for bidirectional IO needed for semi-hosting. This is not possible with the Output Tab. It was a long-standing request from users and believe me, it was a ton of work.

[efox29]

I am having the same issue. I rolled back to 0.4.3 and it works again. Something broke in 0.4.4 that propagated up. I've attached my lauch.json

{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [

    {
        "name": "jlink debug",
        "cwd": "${workspaceRoot}",
        "executable": "${workspaceRoot}/Debug Fast/app.elf",
        "request": "launch",
        "type": "cortex-debug",
        "servertype": "jlink",
        "device": "STM32L151RC",
        "interface": "swd",
        "runToMain": true,
        "svdFile": "svd/STM32L151.svd",
        "showDevDebugOutput": true,
        "preLaunchCommands": [
            "source mygdb.gdbinit"
        ],
       // "preLaunchTask": "Build clean",

    },
    {
        "name": "jlink monitor",
        "cwd": "${workspaceRoot}",
        "executable": "${workspaceRoot}/Debug Fast/app.elf",
        "request": "attach",
        "type": "cortex-debug",
        "servertype": "jlink",
        "device": "STM32L151RC",
        "interface": "swd",
        "runToMain": true,
        "svdFile": "svd/STM32L151.svd",
        "preLaunchCommands": [
            "source mygdb.gdbinit"
        ],          
    }

]

}

[haneefdm]

I can't see your JLink server path. Make sure you are using the CL version of JLink gdb-server -- the non-GUI version.

    "cortex-debug.JLinkGDBServerPath": "C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe",

or

    "cortex-debug.JLinkGDBServerPath": "/Applications/SEGGER/JLink/JLinkGDBServerCLexe",

or whichever is the right path for your OS. If you were using the GUI version, that was never supposed to work as it does not output any status to stdout/stderr

You can also try the latest release

https://github.com/Marus/cortex-debug/releases

[haneefdm]

@robokamran I am gonna close this issue, as I don't think this is a problem. There was also no additional information from you.

[efox29]

I can't see your JLink server path. Make sure you are using the CL version of JLink gdb-server -- the non-GUI version.

    "cortex-debug.JLinkGDBServerPath": "C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe",

or

    "cortex-debug.JLinkGDBServerPath": "/Applications/SEGGER/JLink/JLinkGDBServerCLexe",

or whichever is the right path for your OS. If you were using the GUI version, that was never supposed to work as it does not output any status to stdout/stderr

You can also try the latest release

https://github.com/Marus/cortex-debug/releases

I have in my settings.json

// Cortex-debug related stuff
"cortex-debug.gdbPath": "C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.07/bin/arm-none-eabi-gdb-py.exe",
"cortex-debug.JLinkGDBServerPath": "JLinkGDBServer.exe",

I have the seggar path on my PATH and can run the command from any open terminal.

I tried up to 0.4.6 and none of them works. 0.4.3 was the last version to work.

I have also updated my Seggar tools to the latest (v7.54d).

[haneefdm]

JLinkGDBServer should be JLinkGDBServerCL. That is the command-line (CL) version

[efox29]

That was 100% what it was.

0.4.3 JlinkGDBServer.exe worked (either by design or coincidently). But from 0.4.4 onward, only the CL version.

Made the change in my settings.json to JLinkGDBServerCL and I am able to debug again.

[haneefdm]

Yes, it was a coincidence :-)

[jortbmd]

Hi,

I am having the same issue. The terminal does not auto quit and states:

SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. Waiting for next server session to start...

I cannot quit this process, because it will restart it again.

My launch.json is:

{
  "configurations": [
    {
      "showDevDebugOutput": true,
      "cwd": "${workspaceRoot}",
      "executable": "./build/frimware.elf",
      "name": "Debug STM32",
      "request": "launch",
      "type": "cortex-debug",
      "servertype": "openocd",
      "preLaunchTask": "Build STM",
      "device": "stlink",
      "configFiles": [
        "openocd.cfg"
      ]
    }
  ]
}

I reverted back to 0.4.3 then the process itself is quitable, however it does restart fresh with:

Waiting for gdb server to start...

[haneefdm]

The Terminal window will be there forever unless you quit it, in which case it will (try to) re-start. That is important and by design, so you can look at any issues when the server exits. We may remove the auto-restart if you force quit later, but we need it to be there for now.

You don't want an error to be printed, the server exiting and the window closed? I think you may be confusing a couple of different issues.

90% of our issues are right here in the gdb-server window with half a dozen different gdb-servers behaving differently, USB issues most of which are out of our control.

[jortbmd]

Thanks for the explanation. I understand that you want to keep it open, however as somebody who uses the terminal on a regular basis I rather have it re-open when I open a debugging session.

I also do not really understand why it needs to happen within the terminal, as user interaction is not required can it not be an output channel of the cortex debug extension? This way it does not rely on terminals, it stores all the output and it does not force itself in the terminal window. I don't know if you have considered this option? I am happy to do a pull request to switch it over, if I have some spare time to dive into the code base. As far as I can tell this should be doable.

[haneefdm]

User interaction is indeed required. Which is why it moved here. It is for semi-hosting which is bi-directional. It was in the Output Channel before and people could not find it and caused HUGE support headache. I use the Terminal a LOT as well and I have multiple things going on. The gdb-server never pops to the front (except the first time) and then stays pretty much dormant....until something goes wrong.

[haneefdm]

@jortbmd and thanks for the PR offer. But, we moved it here from the Output channel after a lot of thought.

You can also peel the gdb-server terminal to another window, even to the editor area or one of the side panels. I have not played with it much -- because there is no way for it to remember that setting when you re-start VSCode

[jortbmd]

That explains it and is understandable. Thank you for the explanation! A no semihosting option when launching would be nice. However I can totally get that has some implications and is not on the priority list.

Also I totally forgot to tell you guys. Love the work and many thanks for your efforts!

[robokamran]

@haneefdm I am very sorry for my super late response, aside from being busy, another thing was that all my PCs have stopped showing the error. I really have no idea how it was fixed, I was trying to make the IDE show this problem again but I wasn't successful. IDK what I did to solve this problem. I'm using stm32-for-vscode. I'd appreciate it if you could help on that. Here is my VSCODE settings:

{
  "editor.suggestSelection": "first",
  "vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue",
  "workbench.iconTheme": "material-icon-theme",
  "C_Cpp.updateChannel": "Insiders",
  "cmake.configureOnOpen": true,
  "files.autoSave": "afterDelay",
  "explorer.confirmDragAndDrop": false,
  "window.zoomLevel": 0,
  "editor.lineHeight": 0,
  "editor.fontSize": 13,
  "workbench.startupEditor": "none",
  "http.proxySupport": "off",
  "window.restoreWindows": "none",
  "stm32-for-vscode.openOCDPath": "D:\\PROGRAM FILES\\OPENOCD\\BIN\\OPENOCD.EXE",
  "stm32-for-vscode.makePath": "C:\\PROGRAM FILES (X86)\\GNUWIN32\\BIN\\MAKE.EXE",
  "stm32-for-vscode.armToolchainPath": "C:\\PROGRAM FILES (X86)\\GNU ARM EMBEDDED TOOLCHAIN\\9 2020-Q2-UPDATE\\BIN",
  "security.workspace.trust.banner": "never",
  "security.workspace.trust.enabled": false,
  "security.workspace.trust.untrustedFiles": "open"
}

and here's the .vscode\launch.json

{
    "configurations": [
        {
            "showDevDebugOutput": true,
            "cwd": "${workspaceRoot}",
            "executable": "./build/mytest.elf",
            "name": "Debug STM32",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "preLaunchTask": "Build STM",
            "device": "stlink",
            "configFiles": [
                "openocd.cfg"
            ]
        }
    ]
}

and .vscode\settings.json:

{
    "cortex-debug.armToolchainPath": "C:\\PROGRAM FILES (X86)\\GNU ARM EMBEDDED TOOLCHAIN\\9 2020-Q2-UPDATE\\BIN",
    "cortex-debug.openocdPath": "D:\\PROGRAM FILES\\OPENOCD\\BIN\\OPENOCD.EXE"
}

[haneefdm]

No worries, if it happens again, report back.