Hey Devs,
I migrated my V2 extension to V3 (3.6.4) on Dec 11 2025 (just before the v3.7.0 release), updated my debug workflow / launch.json etc, my STM32H745I discovery board was running my TouchGFX application (basically stock TouchGFX Designer generated app w/ CMake) fine with Dual Core debugging (new shared debugger / simplified Launch/Tasks.json is a massive improvement on my old/convoluted tasks/launcher workflow, my sincere thanks).
Just tried to re-run the same code stack with my code with the new 3.7.0 extensions, hit a launch error relating to my launch.json:
Extension seems to have lost context of my ide.store.json files in the project subfolders:
{
// 'CM4/.settings/ide.store.json' - This line not in actual file
"device": "STM32H745XIH3",
"core": "Cortex-M4",
"order": 0,
"toolchain": "GCC"
}(Similar for the CM7 version targeting the M7 core)
Re-running the STM32Cube Project setup configuration didn't seem to fix it, so I just added 'deviceName' and 'deviceCore' manually to my launch file CM4/CM7 configurations, but would ideally like that bug fixed for dual core projects)
Now running my "DualCore_Debug" compound config throws a gdb server startup issue on the CM4 half of the attach:
With an underlying warning on the CM4_Debug log:
'From Debug Session: step debug conf validation: No image file loaded, see imagesAndSymbols attribute in the debug configuration.'
And the CM7 debugger runs as normal / stops at main, but messes with the dual core startup ASM file timing (stock CM4 domain stop and wait for CM7 configure / continue) so that my application won't initialise correctly, the build is fine, as my app will run in flash / non-debug mode.
Here is my launch.json file (working 3.6.4, no longer in 3.7.0)
{
// 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": "CM7_Debug",
"type": "stlinkgdbtarget", // Debugger type (STMicroelectronics ST-LINK GDB server)
"request": "launch", // Launch a new debug session
"cwd": "${workspaceFolder}",
"preBuild": "${command:st-stm32-ide-debug-launch.build}",
"runEntry": "main",
"deviceName": "STM32H745XIH3",
"deviceCore": "Cortex-M7",
"serverShared": true, // Allows sharing the debug server with other sessions (needed for multi-core)
"serverHaltAllCores": true, // Halts all cores when starting the debug session
"svdPath": "${env:STM32CLT_PATH}/STMicroelectronics_CMSIS_SVD/STM32H745_CM7.svd", // SVD file for CM7 core
"serverExtLoader": [
{
"loader": "${env:STM32CLT_PATH}/STM32CubeProgrammer/bin/ExternalLoader/MT25TL01G_STM32H745I-DISCO.stldr",
"initialize": true
}
],
"imagesAndSymbols": [
{
"imageFileName": "${workspaceFolder}/CM4/build/STM32H745I_DISCO_CM4.elf" // Loads the CM4.elf image
},
{
"imageFileName": "${workspaceFolder}/CM7/build/STM32H745I_DISCO_CM7.elf" // Loads the CM7.elf image
}
],
"verbose": false // Disables verbose logging
},
{
"name": "CM4_Debug",
"type": "stlinkgdbtarget",
"request": "launch",
"cwd": "${workspaceFolder}",
"runEntry": "main",
"deviceName": "STM32H745XIH3",
"deviceCore": "Cortex-M4",
"serverShared": true,
"serverApID": "3", // Specifies the Access Port ID for the CM4 core (core selection)
"serverPort": "61239", // Port for the GDB server to connect (must be unique if running multiple sessions)
"serverReset": "None", // No reset when starting this debug session
"svdPath": "${env:STM32CLT_PATH}/STMicroelectronics_CMSIS_SVD/STM32H745_CM4.svd", // SVD file for CM4 core
"imagesAndSymbols": [
{
"symbolFileName": "${workspaceFolder}/CM4/build/STM32H745I_DISCO_CM4.elf" // Loads the CM4.elf symbols
}
],
"verbose": false
}
],
"compounds": [ // Compound configurations allow (attempted) simultaneous debug sessions
{
"name": "DualCore_Debug",
"configurations": ["CM7_Debug", "CM4_Debug"] // List of configurations to launch together
}
]
}Can you please recommend any launch.json changes required to match the patches in 3.7.0?
Or otherwise let me know if it's an issue with the version update, it seems that Ln50 of the launch.json is the source of the issue, gdb no longer being okay with just a symbol file load.
Env:
OS: Win11 Pro
VSC: 1.108.0
STM32Cube VSC Ext: 3.7.0
- See attached vsc-stm32-proj-extensions.txt for relevant sub extension versions
Board: STM32H745I-DISCO
