Unable to start a debug session using `"servertype": "external"`, running `ST-LINK_gdbserver.exe`

[daantimmer]

After connecting (and it seems like flashing the MCU does work) but afterwards I get:

Failed to launch GDB: Protocol error with Rcmd (from interpreter-exec console "monitor reset halt")

I've tried launching ST-LINK_gdbserver.exe in two ways:

C:\\ST\\STM32CubeIDE_1.10.0\\STM32CubeIDE\\plugins\\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.300.202203231527\\tools\\bin\\ST-LINK_gdbserver.exe -p 50000 -cp C:\\ST\\STM32CubeIDE_1.10.0\\STM32CubeIDE\\plugins\\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.300.202205161323\\tools\\bin --swd --halt

and

C:\\ST\\STM32CubeIDE_1.10.0\\STM32CubeIDE\\plugins\\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.300.202203231527\\tools\\bin\\ST-LINK_gdbserver.exe -p 50000 -l 1 -d -s -e -cp C:\ST\STM32CubeIDE_1.10.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.300.202205161323\tools\bin -m 0 -k

The first entry is the way that cortex-debug launches ST-LINk server, the second one is something random I found by googling.

I can see that cortex-debug connects to the server, it flashes the device, and then it gives the failed to launch error.

[haneefdm]

When you use the "external" server type, we know less than nothing about your server, you get some default behavior for reset/halt/etc. (which I think were borrowed from OpenOCD) You need to customize the startup commands so that for "launch", the startup sequence finishes and the program halts at the reset handler.

You can use overrideLaunchCommands. There are a ton of override/pre/post settings that you use to customize. see

https://github.com/Marus/cortex-debug/blob/master/debug_attributes.md
https://github.com/Marus/cortex-debug/wiki/Overview

When you use "external" type, then you have to know how your gdb-server works -- all the commands, what they do, what errors/side-effects you can have, what command-line args to use, etc. You own every aspect of the gdb-server.

For instance, st-link server does not understand the command reset halt, It is just reset if you are also using the --halt option on the command line. But our default is reset halt`

If we have an implementation, then you can also look at what we do (either in the Debug Console with debug enabled) or in the source code.
https://github.com/Marus/cortex-debug/blob/master/src/stlink.ts

May I ask why you are just not using our implementation? With all the customizations we already allow.

Also, make sure you are using the latest pre-release of our extension available from within VSCode. Also, include the full output of the Debug Console with debug enabled as shown in the Console itself. You also have to become comfortable interpreting this output if you use the "external" type. There is nothing secret we do. Everything is open-kimono, printed to the Console.

[daantimmer]

We(/I) are in the process of moving all development directly from within Docker. That is, using the 'clone repository in docker' option from vscode. (This speeds up compilation about 20x)

From this remote container there is no way to access attached USB devices for programming and debugging. That's why we need to use a TCP/IP connection out of the container in to a GDB server.

[daantimmer]

To respond to your suggestion, that indeeds work, to just use monitor reset:

        {
            /// rest
            "servertype": "external",
            "gdbTarget": "host.docker.internal:50000",
            "overrideLaunchCommands": [
                "monitor reset",
                "-target-download",
                "monitor reset"
            ],
            "overrideRestartCommands": [
                "monitor reset"
            ],
        }

I do wonder why (this is not on your side ofc.) why the behaviour of the stlink gdb server differs between external and 'local', because it is the same executable (stlinkgdbserver) that is opened.

I hope that at least this issue finds its way to other people facing this issue.

Also in the documentation it says to use target-download, but I had to use -target-download.

[haneefdm]

When it is "external", we have no idea what server/executable you are running. How would we? It could even be something we never knew about. We just let gdb connect to a socket that can even be another machine as well. We are not even involved in the actual connection process.

I edited the documentation to add the missing -. Thanks.

In our launch commands for ST-Link, we actually have four commands, the last one being monitor halt which may not be needed but we do it anyway. Just FYI

[daantimmer]

Perhaps an idea to allow setting external type somewhere? You (the extension) might not know what the external server type is. But usually we do.

…

On Fri, 1 Jul 2022, 16:58 Haneef Mohammed, ***@***.***> wrote: When it is "external", we have no idea what server/executable you are running. How would we? It could even be something we never knew about. We just let gdb connect to a socket that can even be another machine as well. We are not even involved in the actual connection process. I edited the documentation to add the missing -. Thanks. In our launch commands for ST-Link, we actually have four commands, the last one being monitor halt which may not be needed but we do it anyway. Just FYI — Reply to this email directly, view it on GitHub <#688 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7IZXKV5PUZJGAP2BWFUQTVR4BQ3ANCNFSM52ML7BTA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[haneefdm]

I will think about it.