Missing the tasks.json file required for code flash.

[horizon105457]

I’m using the pre-release STM32Cube for Visual Studio Code (v3.5.1).
After importing a project that was originally generated by STM32CubeMX with the “cmake” toolchain selected, the .vscode folder is created but contains neither tasks.json nor launch.json.

When I try to add tasks.json manually, the command palette no longer offers the usual templates such as “STM32: CubeProg: Flash project (SWD)”.

Could you confirm whether this is a regression in 3.5.1?
If an immediate fix isn’t possible, would you mind sharing the correct tasks.json and launch.json snippets so I can paste them in by hand?

 

Test conducted on July 28, 2025, testing platform Ubuntu 22.04+vscode(v1.102.2)+pre-release STM32Cube for Visual Studio Code (v3.5.1), test target STM32G474RET6.

[vincent_grenet]

@horizon105457 it's not a regression it's a choice as part of new experience we want to propose.
As always pro & cons. We are happy to get your comments here. We aim to be driven by end users feedbacks. Feel free to share !

You're right <=2.2.1 extension was promoting at STM32CubeMX project import couple of launch.json and tasks.json files. One way was convenient, the other was hard coding too much settings to project structure & co promoted by us. We have ambition to relax end user creativity and support more custom (and possibly more complex, wide, ...) way of working.

 

So starting 3.4.11 extension versions (currently all pre-release to collect feedbacks) the experience has been updated a bit:

+ Already no need any more to import a project what is not so VSCode way of working. You just have now to add a project your VSCode workspace and like CMake tools extension is doing we are discovering live if added material may be a STM32Cube candidate. As end user you have to confirm it or not.

Part of new experience .. we are forcing nobody: end user has to get the control.
+ Once your project is a STM32Cube one, launch.json (and device flashing coming with) is generated either live under the hood pushing "Run & Debug" button

or if more control required, you can ask for "create a launch.json file" or add an extra configuration if exists already.
Based on launch.json we are fully supporting rich editor experience ... please rely on code completion to access the power of rich debug session we are supporting.

Such said you are in control to create by yourself all tasks you want adapting to your way of working. Brand new STM32Cube bundles based architecture is promoting you all STM32Cube available as a CLI. For example from VSCode integrated terminal STM32CUbe programmer is ready for you. Have a try about:

cube programmer --help

you can flash erase:

cube programmer -c port=SWD -e all

or program:

cube programmer -c port=SWD -d <binary file>

 or ...
The very same you cam build:

cube cmake ....

 

[Zeno]

Hi @vincent_grenet 

 

I've stumbled upon a problem in this. I recently upgraded the extensions as well but I think that it does not migrate the launch.json files properly. 

I followed the advice here to remove all existing launch.json configs and just use the cmake run&build but he's unable to perform the dual core run/debugging.

I've had a setup for a dual core STM32H755ZIT6 MCU but after opening up the project using the new extension I'm unable to simply configure a run or debug configuration for both cores. Could you assist in this? 

[Florent V]

Hi Zeno,

For your dual core H755, you need to create 2 debug configurations

In the launch.json file, I start with my CM7 first in this example:

 "configurations": [
 {
 "type": "stlinkgdbtarget",
 "request": "launch",
 "name": "CM7",
 "origin": "snippet",
 "cwd": "${workspaceFolder}",
 "preBuild": "${command:st-stm32-ide-debug-launch.build}",
 "runEntry": "main",
 "serverShared": true,
 "serverHaltAllCores": true,
 "imagesAndSymbols": [
 {
 "imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context2}"
 },
 {
 "imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
 }
 ]
 },
 {
 "type": "stlinkgdbtarget",
 "request": "launch",
 "name": "CM4",
 "origin": "snippet",
 "cwd": "${workspaceFolder}",
 "preBuild": "${command:st-stm32-ide-debug-launch.build}",
 "runEntry": "main",
 "serverShared": true,
 "serverReset": "None",
 "serverPort": "61239",
 "imagesAndSymbols": [
 {
 "symbolFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
 }
 ]
 }
 ]

 

Important points regarding the attributes:

For the CM7 debug configuration:

• imagesAndSymbols:
  You must load both binaries, either by specifying the paths directly or by using VSCode commands. The VSCode command will let you choose thanks to a quick pick the binary for each context (if both are built).
  Be careful, the order matters. Since this is my debug configuration for the CM7, it will be last in my list (i.e., the one for "context1" according to my VSCode command).
• serverShared: necessary for multicore debugging.
• serverHaltAllCores: to stop all cores when debugging starts after flashing.

For the CM4 debug configuration:

• imagesAndSymbols:
  Here, you should use the symbolFileName attribute to load only the symbols without flashing. We only need to specify the CM4.
• serverShared: necessary for multicore debugging
• serverReset: set to "none" to avoid resetting. We do hot attach.
• serverPort: because otherwise it will use the same default port (61234) as the CM7 configuration.

Kind Regards,
Florent

[horizon105457]

I manually added the following task.json file, and now I can compile and upload by running the task, which is in line with my previous EIDE habits.

{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "shell",
			"label": "build",
			"command": "${command:st-stm32-ide-debug-launch.build}",
			"args": [],
			"group": {
				"kind": "build",
				"isDefault": true
			},
			"problemMatcher": []
		},
		{
			"type": "shell",
			"label": "flash-with-cubeprogrammer",
			"command": "${command:st-stm32-ide-debug-launch.get-programmer-path}/STM32_Programmer_CLI",
			"args": [
				"-c",
				"port=SWD",
				"-d",
				"${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
			],
			"group": {
				"kind": "build",
				"isDefault": false
			},
			"problemMatcher": [],
			"dependsOn": [
				"build"
			]
		}
	]
}

If there are better solutions, please be sure to share them with us.

[jvmp]

I tried the above solution myself, but it didn't work as is, so I checked the tasks.json file from the previous STMCube VSCode extension and saw that the Flash task had

"-hardRst",
"-rst",
"--start"

at the end. The code that works for me now looks like this:

{
 "version": "2.0.0",
 "tasks": [
 {
 "type": "shell",
 "label": "Build",
 "command": "${command:st-stm32-ide-debug-launch.build}",
 "args": [],
 "group": {
 "kind": "build",
 "isDefault": true
 },
 "problemMatcher": []
 },
 {
 "type": "shell",
 "label": "Flash",
 "command": "${command:st-stm32-ide-debug-launch.get-programmer-path}/STM32_Programmer_CLI",
 "args": [
 "-c",
 "port=SWD",
 "-d",
 "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}",
 "-hardRst",
 "-rst",
 "--start"
 ],
 "group": {
 "kind": "build",
 "isDefault": false
 },
 "problemMatcher": [],
 "dependsOn": [
 "Build"
 ]
 }
 ]
}