STM32CubeIDE migration to VSCode problem

[zd29086]

We have a project which uses STM32CubeIDE (Eclipsed-based). It has a Makefile which we use to compile the code and upload the code to the target. Since I know ST has made a new STM32CubeIDE VSCode extension, I wanted to have a trial to see if I can convert the existing Eclipsed based project to VSCode based project. I installed the STM32CubeIDE extension in VSCode and other necessary components. I followed the migration guide to generate a CMake project using STM32CubeMX. However, it never worked since the new CMake file doesn’t take what the original Makefile does in my project. It missed a lot of compiler and scripting options. After the migration, the build process failed and never succeeds. Since Makefile works great in the original project (either in CLI/GUI mode), why does the migration require user to convert it to CMake? Many Unix/Linux users prefer Make instead of cmake. It gives you better control over the source code. I would suggest ST that if you really want to make a VSCode extension for ST developers, you should support Makefile as the default toolchain, not cmake.

[Cartu38 OpenDev]

​@zd29086 
Which migration guide are you speaking about ? Could you share link to I’ve some interest.

Such said, myself I’ve success converting Eclipse based project to CMake Thanks STM32CubeIDE for Visual Studio Code dedicated feature:
 

Have you got a try ?

 

[zd29086]

This is the migration guide I used (AI generated with steps quoting from ST websites)

 

Step 1: Install the VS Code Extensions

• Open Visual Studio Code.

• Navigate to the Extensions view (Ctrl+Shift+X or Cmd+Shift+X).

• Search for and install the official STM32CubeIDE for Visual Studio Code pack. This installs the necessary compiler management, CMSIS-PACK support, and Debug Adapter Protocol (DAP) tools. [1, 2]

Note: Make sure your ST-LINK USB drivers are updated on your system so VS Code can communicate with your hardware. [1]

Step 2: Convert the Project Toolchain to CMake

Because the VS Code extension depends on CMake, you must update your project's target toolchain using the standalone configuration tool. [1, 2]

• Close STM32CubeIDE.

• Open your project's .ioc file directly inside the standalone STM32CubeMX application. (Do not use the internal device configuration plugin inside STM32CubeIDE, as it locks the toolchain dropdown). [1, 2]

• Go to the Project Manager tab. [1]

• Under Toolchain / IDE, change the selection from STM32CubeIDE to CMake. [1]

• Click Generate Code in the top right. This creates the necessary CMakeLists.txt files without deleting your custom source directories. [1, 2]

Step 3: Import and Configure in VS Code

• Launch VS Code and select File > Open Folder..., then select your project's root folder. [1]

• The STM32 extension will trigger an Auto-Discovery prompt to set up your environment. [1]

• Run the "Import CMake Project" command if prompted by the extension. [1]

• The integrated bundle manager will automatically fetch the required GNU Arm Embedded Toolchain compiler and MCU support packages, meaning you do not need to manually configure system path variables. [1, 2]

Step 4: Build and Debug

• To Build: Use the default CMake build shortcut (F7 or click the build icon on the status bar).

• To Debug: Press F5. The extension utilizes a native Debug Adapter Protocol (DAP) that auto-detects your connected ST-LINK or SEGGER J-Link probe.

However, the CMakeLists.txt doesn’t map to the original Makefile correctly. Although I added all compilation options in CMake, it failed the build process. I also used the above “Convert Eclipsed STM32CubeIDE project” menu but it doesn’t build either. My original Makefile works great in both CLI and GUI.

 

[Cartu38 OpenDev]

​@zd29086 

To my knowledge relying on MX to convert has no chance to be successful. Rational is MX is not aware about your custom extra files. CMake world all sources have to be explicit as part of resulting CMakeList.txt file.

So AI is wrong.

 

Dedicated conversion feature should work. Sounds like a bug ST may support you. You are on right forum.

 

Is your project complex a way or another like relying on some pre or post buil commands or adressing multicontext target device or ... ?

Which device are you targetting by the way ?

To help a bit : any trace to share about conversion process ? Log is part of project manager output channel.

[Cartu38 OpenDev]

​@zd29086 

Any update ?

[zd29086]

I just tried another time using STM32CubeIDE VSCode extension “Convert Eclipse STM32CubeIDE project” menu. It still failed.  The error log shows that. My target MCU is STM32F7. My Makefile is a standard GNU Makefile with some STM32 linkerscript. There are some OpenOCD scripts for flashing target in Makefile.

2026-10-06 09:55:05.869 [Info] [ide-project-convert] Starting project conversion...

2026-10-06 09:55:06.631 [Info] [ide-project-convert]  cube wrapper version: 0.10.4

2026-10-06 09:55:07.449 [Info] [ide-project-convert] Invoking STM32CubeIDE Eclipse exporter...

2026-10-06 09:55:17.843 [Info] [ide-project-convert] Generating project...

2026-10-06 09:55:18.973 [Error] [ide-project-convert] Inconsistent source files found across project configurations is not supported.

2026-10-06 09:55:19.004 [Error]  [ide-project-convert]: Project conversion failed with exit code: 43.

 

[Cartu38 OpenDev]

​@zd29086 
Issue is self explicit. You’re facing an unsupported project setup.

Could you have a try - doing first a copy or source control of your project - to keep a single build configuration prior exercising the conversion process ?
Most probably you’ve extra sources as part of a Debug configuration compared a Release one or something like. Sounds not supported for now at least.

[zd29086]

​@Cartu38 OpenDev 

Thanks for your suggestions. I tried your approach but still didn’t work. So I’m not going to spend any time in converting this project since I have spent several days trying to figure it out without success. I’m happy with my Makefile setup since it just works. I’m curious if STM32CubeIDE VSCode extension supports Makefile project (not CMake). Right now, if I use VSCode without STM32CubeIDE extension, it works fine for code build and code navigation, but I can’t do debugging.

[Andrew Neil]

prefer Make instead of cmake. It gives you better control over the source code

Does it ?

[zd29086]

Makefile has been used by almost every Unix/Linux developer for decades. CMake is just a high-level wrapper around other build system (Make, Ninja, etc.). The underlying new Ninja build system is buggy for embedded system project. So I think sticking with traditional Makefile should be a better choice than using CMake if ST wants to introduce the VSCode extension.

[Cartu38 OpenDev]

​@zd29086 

You’re right about CMake which is in real a build system generator. One of possible CMake output is Make …
I would like to get more hints about Ninja lacks you’re discussing about … I’ve never got comment as such about but just interested into for my own knowledge.

[zd29086]

That is what I did in the first pass. I regenerated the project with STM32CubeMX, and then configured VSCode to use the correct ARM GCC toolchain. I also modified the auto-generated CMake file to be exactly equivalent to the original Makefile. But the build still failed with weird error messages. Then I cleaned up everything and adopted the second approach: Using “Convert Eclipse STM32CubeIDE project” menu from STM32CubeIDe VSCode extension. But it failed again with the above errors. So I decided going back to using my original Makefile project, which works great and seamlessly.

[Cartu38 OpenDev]

​@Ali Kumail 

Can work if you’re not adding extra files to MX project. If some - what is kind of common - MX cannot be aware of. It’s not killer you can always add them to new build system but MX will not do it for you. You cannot just ask for MX generation and hope to get any chance your build being success. So the converter feature interest.

[Julien D]

Hi ​@zd29086,

As ​@Cartu38 OpenDev stated earlier, the Inconsistent source files found across project configurations is not supported. error message means that your STM32CubeIDE project has several build configurations (maybe Debug and Release), but all configurations are not using the exact same set of source files. This is a known limitation, which hopefully will be addressed in the future.

To confirm this, could you check or share (here or by PM) the stm32cubeide-export.json file which should be produced into the destination folder?