VSCode extension build and only flash program

[maze2go]

I started using stm32 MCU's on my university. There we used the CubeIDE. Now I have a board at home for own projects. I wanted to use VSCode with the new extension, because i prefer it over Eclipse / CubeIDE. Now I have two questions. I can debug my program via vscode, but I found no option to just flash it onto the board without debugging. (Where) can I do that?

Another questions that came into my mind related to that is, if I could just build my project without flashing it like you can do it on CubeIDE. When I press CTRL + P in vscode and press run build task i get an error:

FAILED: LED_TEST.elf 
cmd.exe /C "cd . && C:\ST\STM32CubeIDE_1.13.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.0.202305231506\tools\bin\arm-none-eabi-gcc.exe -fdata-sections -ffunction-sections --specs=nano.specs -Wl,--gc-sections -g -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -T C:/Users/Matth/Desktop/LED_TEST/STM32G431KBTX_FLASH.ld CMakeFiles/LED_TEST.dir/Core/Src/main.c.obj CMakeFiles/LED_TEST.dir/Core/Src/stm32g4xx_hal_msp.c.obj CMakeFiles/LED_TEST.dir/Core/Src/stm32g4xx_it.c.obj CMakeFiles/LED_TEST.dir/Core/Src/syscalls.c.obj CMakeFiles/LED_TEST.dir/Core/Src/sysmem.c.obj CMakeFiles/LED_TEST.dir/Core/Src/system_stm32g4xx.c.obj CMakeFiles/LED_TEST.dir/Core/Startup/startup_stm32g431kbtx.s.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_cortex.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_dma_ex.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_dma.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_exti.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_flash_ex.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_flash_ramfunc.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_flash.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_gpio.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_pwr_ex.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_pwr.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_rcc_ex.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_rcc.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_tim_ex.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_tim.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_uart_ex.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_uart.c.obj CMakeFiles/LED_TEST.dir/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal.c.obj -o LED_TEST.elf   && cmd.exe /C "cd /D C:\Users\Matth\Desktop\LED_TEST\build\debug\build && C:\ST\STM32CubeIDE_1.13.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.0.202305231506\tools\bin\arm-none-eabi-size.exe C:/Users/Matth/Desktop/LED_TEST/build/debug/build/LED_TEST.elf && cd /D C:\Users\Matth\Desktop\LED_TEST\build\debug\build && C:\ST\STM32CubeIDE_1.13.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.0.202305231506\tools\bin\arm-none-eabi-objcopy.exe -O ihex C:/Users/Matth/Desktop/LED_TEST/build/debug/build/LED_TEST.elf LED_TEST.hex && cd /D C:\Users\Matth\Desktop\LED_TEST\build\debug\build && C:\ST\STM32CubeIDE_1.13.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.0.202305231506\tools\bin\arm-none-eabi-objcopy.exe -O binary C:/Users/Matth/Desktop/LED_TEST/build/debug/build/LED_TEST.elf LED_TEST.bin""
Der Befehl "cmd.exe" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
ninja: build stopped: subcommand failed.
build finished with error(s).

It sais that the command "cmd.exe" is misspelled  or could not be found.

[Pavel A.]

Hi,

A short answer: the VS Code extension looks nice and promising - but it is not quite mature yet. The debugger is the most crucial and valuable part of the developer environment. So, if you know Eclipse at all and can use it, please do yourself a favor and do so. Be productive and (almost) happy. Use the VS Code stuff when it is ready for  prime time (or when you feel like improving it and contribute to the community ;)

[maze2go]

Thank you for your reply. I already noticed that the extension is not very mature. But is there a way to do my above mentioned things?

[Pavel A.]

Of course, many users do this many times every day. Just create a "Run" configuration in CubeIDE, it is similar to "Debug" but stops after loading the program. Another way: use the CubeProgrammer, ether GUI or command line variant. It is a special tool for putting the program on the MCU.

[Astrojoin]

This is the structure of the launch configuration for VSCode, where it needs to be changed to perform flash only

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch",
      "type": "cppdbg",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "program": "${command:cmake.launchTargetPath}",
      "MIMode": "gdb",
      "miDebuggerPath": "${command:vscode-embedded.st.gdb}",
      "miDebuggerServerAddress": "localhost:3333",
      "debugServerPath": "${command:vscode-embedded.st.gdbserver}",
      "debugServerArgs": "--stm32cubeprogrammer-path ${command:vscode-embedded.st.cubeprogrammer} --swd --port-number 3333",
      "serverStarted": "Waiting for connection on port .*\\.\\.\\.",
      "stopAtConnect": true,
      "postRemoteConnectCommands": [
        {
          "text": "load build/debug/build/Button.elf"
        }
      ],
      "logging": {
        "engineLogging": true
      },
      "preLaunchTask": "Build",
      "svdPath": "${command:vscode-embedded.st.svd}/STM32F103.svd"
    }
  ]
}

[Astrojoin]

After some working, i finalized a launch.json tha actually flash the microcontroller and then disconnects, but due to early exit of the script VSCode warns about "GDB exited unexpectedly". It works but this script ends with this warning.

    {
      "name": "Program target board",
      "type": "cppdbg",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "program": "${command:cmake.launchTargetPath}",
      "MIMode": "gdb",
      "miDebuggerPath": "${command:vscode-embedded.st.gdb}",
      "miDebuggerServerAddress": "localhost:3333",
      "debugServerPath": "${command:vscode-embedded.st.gdbserver}",
      "debugServerArgs": "--stm32cubeprogrammer-path ${command:vscode-embedded.st.cubeprogrammer} --swd --port-number 3333",
      "serverStarted": "Waiting for connection on port .*\\.\\.\\.",
      "stopAtConnect": false,
      "postRemoteConnectCommands": [
        {"text": "load build/debug/build/Button.elf" }, 
        { "text": "detach"},
        { "text": "disconnect", "ignoreFailures": true},
      ],
      "logging": {
        "engineLogging": true,
        
      },
      "preLaunchTask": "Build",
      "svdPath": "${command:vscode-embedded.st.svd}/STM32F103.svd"
    },

[Pavel A.]

> "GDB exited unexpectedly"

The type should be something else, not "cppdbg"?

[Astrojoin]

"cppdbg" is the default tool provided with the official VSCode STM32 Extension so this is a minimum intrusive change to make the whole thing works as spected.

[Pavel A.]

Try a different port number, not 3333 ?

[mattias norlander]

Sorry to resurrect this old thread.
I agree with Pavel's statements.

We released yesterday a new version of the VS Code extensions. The previous version was not very stable / mature and had far too many dependencies. The new version (2.0.1) strips a lot of dependencies and thereby gets rid of "magic stuff" going on under the VS Code hood. Nobody likes "magic black boxes". Hopefully the new version is much more transparent vs previous version.

Feel free to give it a try. This is a new start and a breaking change. Porting existing projects is a bit messy but described in the Userguide.md (part of VS Code extension). Starting a new project from scratch should however be much more simple than before.
Pre-requisites: STM32CubeMX 6.11.0 and STM32CubeCLT 1.15.0

As Pavel phrased it the question is how to be "productive and (almost) happy".
I think the new VS Code extension will be a much better starting point. It does not bring all advanced debug features. But STM32CubeIDE can be used side-by-side to only benefit from its debug features while managing the code base (edit/compile) from VS Code. I just dropped a screenshot on how to do that here:

https://community.st.com/t5/other-tools-mcus/new-stm32-vscode-extension-v2-0-0-released/td-p/657415

Kind regards, Mattias