Skip to main content
KMill
Senior
July 27, 2026
Question

How do I create debug and release profiles for a project?

So I have an STM32 project in VSC and when I first set up this project and started debugging, I vaguely remember being asked by VSC to create a launch.json file.

Now it seems I can build a ‘debug’ session, and launch it, and debug with all the usual features like step-in, step-out, continue, and so on. But how do I now add a ‘release’ build, which strips debug info and allows me to program a device without debugging it?

 

[I am trying to be a good citizen and get along with STM32 for VSC, but so far it seems like i) A retrograde step ii)A mix of modern UI’s and very old looking Java (MX) and iii)You need a science degree in CMAKE to understand anything. ]

My launch.json looks like this:

{
// 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": [

{
"type": "stlinkgdbtarget",
"request": "launch",
"name": "STM32Cube: Launch ST-Link GDB Server",
"origin": "snippet",
"cwd": "${workspaceFolder}",
"preBuild": "${command:st-stm32-ide-debug-launch.build}",
"runEntry": "main",
"imagesAndSymbols": [
{
"imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
}
]
}
]
}

 

15 replies

Cartu38 OpenDev
Graduate II
July 27, 2026

​@KMill 

Thanks this line 

"imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"

used binary (flashed one) at debug session launch time is dynamic.

It relies on your active project context. Active context is mastered by CMake Tools extension:

Elect the one you want to shoot for !

If you dislike this you can just hard code kind it:
 

 

Cartu38 OpenDev
Graduate II
July 27, 2026

​@KMill 

Since you're a "good citizen" here, I’d love it if you could elaborate on your points: "i) A retrograde step, ii) A mix of modern UIs and very old-looking Java (MX), and iii) You need a science degree in CMake to understand anything."

Whether or not I agree, all feedback matters. Explicit comments are the only way we can drive progress.

Feel free to share more—don't be shy!

KMill
KMillAuthor
Senior
July 28, 2026

The VSC is good editor, mayeb not as good as Xcode, but a pretty nice modern looking editor for code.

But then you have to jump to CUBE MX for device configuration. It has a UI very fiurmly stuck in the late 90’s early 2000’s. And it has to jump out to Java to do it. In fact on modern macOS machines when you launch Cube MX from within VSC the dock shows the app-name as “java”.

 

Project settings are a opague - you only know what you are doing if you know what you are doing. No UI to guide. And yes I hear you, UI’s aren’t everything and require tons of maintenance, but it’s quite a step back from project configuration pages in things like Xcode on mac. 

I call it a retrograde step because it feels like they jumped from CubeIDE to VSC in order to take advantage of the great editor and file handling, but everything else feels cludgy and bolt-on.  There’s no doubt that CubeIDE was past it’s time but at least everything was in one place and had a consistent look and feel.

Cartu38 OpenDev
Graduate II
July 28, 2026

​@KMill 

Thanks for sharing your extra thoughts—much appreciated! I might share some of your comments.

CubeMX is still Java-based, yes. ST is making a good move toward new technologies with MX2, but the complete STM32 portfolio isn't supported there yet.

 

I feel like VS Code has a more 'DIY' DNA, which might explain the lack of UI polish.

To all community fans, what are your thoughts on this? I'm interested to get extra feedback.

MM..1
Super User
September 5, 2026

FYI using release is waste of time and space on disc. Real binary file in flash is exactly same for debug and release confs with same optimize setup. Different is only elf file...

Cartu38 OpenDev
Graduate II
September 6, 2026

​@alikhan 

CMake is your best friend. Full flexibility is ready for you. Let's rely on CMakePresets.json file. 

Ps: no GUI available. Edit mode is the way of working.

Note: Have a try to generate a so called empty project. You will get an template kind.

KMill
KMillAuthor
Senior
September 7, 2026

Thanks everyone for all the encouragement and updates.

Since posting this I have also started a project which uses Nordic Semi devices and it also uses VSC - but it does it really well! It’s device tree editor is second to none, similar in ways to Cube MX but far more modern and context aware…. and their devices are Arm Cores just like ST’s devices.

However Nordic and STM32 don;t co-exist well in VSC - I had to send them to separate rooms by creating Profiles in VSC. They are both CMAKE based. Beofre using ‘profiles’ if I opened a Nordic project the STM32 popup would jump an and prompt me to convert it to an STM32 Cmake project. Play nicely guys!

Another trick ST could learn from Nordic’s implementation: when I add a .c/.h file pair to my Nordic project I get a popup that says (I am paraphrasing here) “Hi, you’ll need to add that C file to your CMakeFiles.lst - I can see you have multiple CMakeFiles which one would you like to add it too. This one at this line, or this one at this line?” - Simples!

Still STM32 is my go-to product range for all my projects, and I am slowly getting my head around CMake so I guess that’s good.

 

One more thing…. ​@MM..1  I’m not sure it’s correct to say debug and release binaries are the same. A debug release will have different optimisations, less ethereal structures and more volatiles. Unless you just cloned your debug setup and called it ‘release’ there should definitely be binary differences.

Cartu38 OpenDev
Graduate II
September 7, 2026

​@KMill 
I’m with you about Debug & Release. 
​@MM..1 is right on one hand but real life is most of time main variation between Debug & Release are compiler optimization and or specific symbols enabling tracing or … what cannot be managed Thanks a single configuration.

MM..1
Super User
September 7, 2026

Ofcourse real life i use many defines for testing, but here i write use more as one config is waste of space and time, because switching produce full rebuilds and ​@KMill  confs with same optimize setup produce same hex and bin.

gcc -g ( include debug info)  is on my understanding primary debug config.

gcc -O is optimize level and i prefer testing my embedded always in level for "release” …

 

Cartu38 OpenDev
Graduate II
September 7, 2026

​@KMill 

About “if I opened a Nordic project the STM32 popup would jump an and prompt me to convert it to an STM32 Cmake project” is true.

Being fair you could add you’re getting a proposal notification you can cancel … nobody is forcing you to apply STM32Cube style on top of a Nordic project.

I’ve read rational about this behavior Thanks another post / discussion (sorry I do not have reference and this forum search facility is  … to be improved - my taste -): idea is despite STM32Cube assets are installed, they are as an extension set to enrich a framework aka. VS Code end user may use to play with STM32Cube or any other activiy. CMake is not only dedicated to STM32Cube so guys are relying first on common Microsoft CMake tools extension (what Nordic is doing’ish too). STM32Cube is so not doing forced association between CMake project & STM32Cube. STM32Cube is looking for CMake project which can be a STM32 one or not … and is proposing to end user to confirm if this CMake project is yes or no a STM32Cube candidate one.
Despiste user experience may be a bit ? if not used to I like myself the fair game to not force us as end user.
Such said I would recommend like you are doing to rely on VS Code profiles to get the stuff clear. I bet main ST issue here is few VS Code end users are profiles aware / used to …

WDTY ?

KMill
KMillAuthor
Senior
September 7, 2026

Well this morning I switched back to my Nordic profile after using my STM32 profile for a while, and it’s broken.

The $PATH in the nRF Terninal is borked and the only thing I’ve been using since last time is the STM32 SDK profile.

So I guess there’s still some work to be done on getting Cmake projects to work nicely with each other in VSC, but all these little broekn things help me to lear more.

If I start from a clean install of all the SDKs and VSC then there is probably a nice clean order of things that lets everything work nicely together, but equally there is probably a not-so-clean order of things that causes one or more previosuly-working things to get broken. I installed Nordic first, then STM32 and now nordic is broken. I’ll try a clean install the other way round and see what happens. 

I actuallyt think it’s the ‘behind the scenes’ command line tools that are breaking things, it seems the order of things in $PATH is very important. 

Or maybe I should stop having a foot in both camps and just chose either Nordic or STM32! lol

Cartu38 OpenDev
Graduate II
September 7, 2026

​@KMill 
Interesting. STM32CubeIDE for VS Code promise is to prevent by construction this pain kind. By construction relies on so called STM32Cube bundles and ‘cube’ command to access resources like utilities (cmake, ninja, debuggers, toolchains, ...). ‘cube’ is managing at invokation time containerized style env. setups. In short with this fresh proposal ST promise is to not require / not act on any system env. update / corruption / ….