Official ST-LINK gdbserver support

ST’s ST-LINK gdbserver from STM32CubeIDE seems to be a lot more stable than OpenOCD for the devices I have been using.

ST-LINK gdbserver manual

On Windows, I run the st-link gdbserver in a separate command line via:

C:\Apps\stm32\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_1.4.0.202007081208\tools\bin\ST-LINK_gdbserver.exe -p 3333 -l 1 -d -s -i 066CFF495652716587091651 -e -cp C:\Apps\stm32\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.4.0.202007081208\tools\bin -m 0 -k

Param	Option
-l	logging verbosity
-d	SWD mode
-s	Flash verify
-i	ST-LINK serial number (optional - will choose the first found when left out)
-e	Persistent (do not quit - most likely do not want this when launching within vscode)
-cp	CubeProgrammer plugin bin path
-m	‘AppID to debug’ (this was grabbed straight from the params STM32CubeIDE supplied launching st-link gdbserver)
-k	Initialise under reset

It also lists options for SWO (which I have yet to get around to trying):

Param	Option
-z	SWO TCP port
-a	MCU clock speed
-b	Clock divider

I use something along the following in the launch.json settings:

{
    "name": "stlink-gdbserver F401RE",
    "type": "cortex-debug",
    "request": "launch",
    "runToMain": true,
    "cwd": "${workspaceRoot}",
    "executable": "${command:cmake.launchTargetPath}",
    "servertype": "external",
    "gdbTarget": ":3333",
    "device": "STM32F401RETx",
    "svdFile": "${workspaceRoot}/Environment/svd/STM32F401.svd",
}

If Cortex-Debug had a new config setting for the st-link gdbserver path, then I’m sure the rest could be pattern matched from that. So given:
C:\Apps\stm32\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_1.4.0.202007081208\tools\bin\ST-LINK_gdbserver.exe

The plugin path, platform and version could be extracted:
plugin path: C:\Apps\stm32\STM32CubeIDE\plugins OS and version: win32_1.4.0.202007081208

With those the -cp argument (CubeProgrammer plugin bin path) could be built: C:\Apps\stm32\STM32CubeIDE\plugins + \com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer. + win32_1.4.0.202007081208 + \tools\bin

I would add this support myself if I knew enough about hacking vscode as I feel it’s such an important option where J-Link hardware is not available. And since STM32CubeIDE is cross-platform a lot of people would benefit from something like this.

If there is absolutely anything I can help out with then don’t hesitate to ask! (related: #333, @haneefdm)

[resonantworks]

Also, this seems to work for attaching to the target without downloading:

{
    "name": "stlink-gdbserver F401RE (attach)",
    "type": "cortex-debug",
    "request": "attach",
    "cwd": "${workspaceRoot}",
    "executable": "${command:cmake.launchTargetPath}",
    "servertype": "external",
    "gdbTarget": ":3333",
    "overrideAttachCommands": [],
    "device": "STM32F401RETx",
    "svdFile": "${workspaceRoot}/Environment/svd/STM32F401.svd",
}

[haneefdm]

Yes, thanks. I close one earlier related to this.