Is anyone using the STM32 VS Code Extension? - Page 1
Forum section: electronics / general

author: betocool
author_rank: Regular Contributor
timestamp: October 16, 2025, 06:56:00 am
content: Hey all,I'd like to get your thoughts and experiences with this. I'm currently still using VS code to edit CubeMX projects and the CubeIDE just for flashing to the device. I haven't updated CubeIDE since version 1.14.0 and so far it still works well for me.I'm tempted to jump onto the STM32 VS Code extension but other than a few YouTube videos I've yet to see compelling arguments to do the switch. On the other hand, I also work with NRF52 devices on VS Code and their SDK as recommended by them so it wouldn't be too dissimilar I guess? NRF52 is also based on CMake, but it forces one to use the complete Zephyr stuff as well as DTS which I'm not a big fan of.Basically, "Is VS Code STM32 Extension a buggy piece of crap?" or notCheers,Alberto

author: Hawaka
author_rank: Regular Contributor
timestamp: October 16, 2025, 07:25:22 am
content: My experience is as follow: I use STM32CubeIDE with a ST probe/debugger at work, and I think it’s pretty good. I says that because I have tried multiple IDE and most of them are worst than STM32CubeIDE.For home project, I use the VSCode STM because that was the only way to make it work with a DAPLink debugger.In the beginning it was painfull to set everything up and understand how cmake works. The editor experience is ok, the debugging isn’t quite as good as STM32CubeIDE, but good enough for me (I cannot tell if it is because I use a non-ST probe or not).I almost don’t use CubeMX, I configure most of the peripheral by hand and don’t really use the HAL function. Sometimes I generate a example project to see how something works, but that’s it.To answer your question "Is VS Code STM32 Extension a buggy piece of crap?" I would say it is totally usable. Configuration at the start of a project is harder, but then it’s fine. You should use it for a week then decide, best way to know.

author: JPortici
author_rank: Super Contributor
timestamp: October 16, 2025, 08:14:12 am
content: How responsive is ST to problems in the VSCode extensions?Microchip has gone the same route with their own VSCode extensions, having to learn a bit of CMake and all that stuff.It took several months since the first betas became available, but to me it seems it's pretty usable at this point and can do about 98% of what MPLABX does (of course i still have a couple of specific things that won't let me migrate *all* project, just most, and some of the debugging tools and controls are simply not there because VSCode doesn't implement them) and that's just because after a bit they decided to listen to the users in the forum, and that helped improving the quality and solving bugs very fast.

author: Hawaka
author_rank: Regular Contributor
timestamp: October 16, 2025, 09:58:38 am
content: I cannot say how responsive ST is. There is an update about once a month, but frankly I haven't seen an improvement.I use the cortex-Debug extension, which is not from ST. I wish a would know more about extension to be able to fix some stuff myself.

author: mark03
author_rank: Frequent Contributor
timestamp: October 16, 2025, 04:53:07 pm
content: Quote from: JPortici on October 16, 2025, 08:14:12 amThey were willing to engage with me on their discussion forums when I reported bugs with the extension. I think it's a high priority for them right now.I never used the old Cube IDE, nor any of the automatic code generation, HAL, or LL libraries. My guess is that the VS Code extension makes a better experience on Linux, because ST is responsible for less of the total footprint, reducing unnecessary bloat (there's still plenty). I'm reasonably satisfied with it after some start-up headaches. The debugging experience is not great, e.g. the fault status registers are conveniently shown but there is no way to look at the fault *address* registers without adding a watch for *(0xe000e...). Peripheral registers are shown but updates are super slow. There's no way to reset the target while debugging, without reflashing your code too. (I may actually hit the flash endurance limit on the H7 Nucleo board I'm prototyping with.) Starting debug seems to get a little bit slower with each invocation, until once a week or so when I close VS Code and kill off orphan processes. Text doesn't intelligently use the full width of the sidebar, forcing me to expand it wider than I should have to, in order to read the register contents.For all of that, it's still VS Code, and still better than Eclipse, if you can hold your nose and not think about the fact that we've traded Java forJavascriptand ElectronShockingly, it seems a change for the better.Honestly, I just want a nice project template for my chosen processor with all the CMSIS files and nothing else. When I told them that they seemed puzzled. Conclusion: if you really want simplicity, invest the time in a nice Makefile setup and use vim and gdb. Failing that, I have found this to be a reasonable compromiseOTOH if you're stuck with the HAL and generated driver code, don't sweat it, because it doesn't matter so much which toolset you use; you'll still be debugging in the dark, the Microsoft way---trying a succession of potential fixes until something "works". I see the new extension as more of a win for people who want their code to make sense.