Stm32CubeIDE for Visual Studio Code - The project conversion tool doesn't copy over assembly files, .s files.

[ad101]

As the title describes, the conversion tool to convert Stm32CubeIDE projects over to Visual Studio Code seems to work. Apart from the fact that, at least in my case, it failed to copy over the assembly files, .s files, in the project.

 

Which led to build errors, specifically thumb mode errors.

Just posting this here so that it may help others. Not quite sure how best else to let others know.

[Nawres GHARBI]

Hi ​@ad101 

do you have any project to share please ?

[Julien D]

Hi ​@ad101,

As Nawres mentioned, could you give more details about your project, especially where the assembly sources are located? Are they in the project tree, or somewhere on disk as linked resources?

I just tried it myself: I defined new asm_utils.s and asm_utils.h files in an empty STM32CubeIDE project, used the functions in main.c, built it successfully in STM32CubeIDE, converted the project in VS Code, and then built it successfully in VS Code too.

I attached the sample.

[ad101]

Hi there,

The files that fail to copy over during the conversion are from the threadx libraries.

The files were missing after the conversion so I had to copy them over and also make changes to the generated .cmake to successfully build.

vscode_generated.cmake:
 

# Add sources to executable/library
target_sources(${BUILD_UNIT_0_NAME} PRIVATE

    …

    # Add the missing low-level initialization assembly file:
    "Core/Src/tx_initialize_low_level.S"

    # Add the missing Core ThreadX Cortex-M33 Assembly ports:
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_context_restore.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_context_save.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_interrupt_control.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_interrupt_disable.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_interrupt_restore.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_schedule.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_stack_build.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_thread_system_return.S"
    "Middlewares/ST/threadx/ports/cortex_m33/gnu/src/tx_timer_interrupt.S"
)

“

STM32CubeIDE

 

Version: 2.1.1

Build: 28236_20260312_0043 (UTC)

”

“
Version: 1.124.0 (user setup)
Commit: 1b50d58d73426c9171299ec4037d01365d995b78
Date: 2026-06-09T21:29:32-07:00
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Windows_NT x64 10.0.26200
“
 

[Julien D]

I’m still struggling to reproduce the issue.

Could you please try the latest version of the converter bundle released last week, ide-project-converter@1.2.1?

There were many improvements, and several example projects have changed from fail to pass status.

If it still fails, could you please send me by private message the STM32CubeIDE project metadata (.project and .cproject files) and the intermediate converter description, which should be part of the generated CMake project (stm32cubeide-export.json)?

[ad101]

 

Hi Julien,

I’m using the “Convert Eclipse Stm32CubeIDE project” command that appears to be part of the STM32Cube Project Manager Extension Pack.

And that looks like it was updated 2 hours ago. And the problem persists, just tried it again. I’ll send those files to you via private message.

 

Alex

[Julien D]

Sorry I had not been precise enough, the ide-project-converter is a bundle, so installed aside vscode extensions.

You can check its version using the bundle manager, system view:

 

[ad101]

Hi Julien,

Ah I see, yeah, the ide-project-converter bundle was on 1.1.1, I believe. Unfortunately, even after updating to 1.2.1, the issue persists.

 

Alex

[Julien D]

Thanks for sharing the files.

Indeed all asm sources from threadx are not listed as sources into the intermediate file so it is “normal” to not have them into the generated cmake project.

Means, if such asm sources are visible and built by STM32CubeIDE, then there is likely an issue with another bundle called osgi-exporter. The latest version is 0.0.5, released a couple of months ago; maybe something to verify on your side before going deeper.

What looks strange at that stage is the fact that apparently the threadx sources are located outside of the STM32CubeIDE project tree, and ../Middlewares/ST/threadx/ports/cortex_m33/gnu/src seems never be referenced. Means I don’t explain how they can be built in STM32CubeIDE neither.

Usually external sources are referenced as Linked Resources from STM32CubeIDE project, and in your case I don’t see any trace of such.

Here is a screenshot using a random cortex m33 threadx example from FW package (STM32Cube_FW_WBA_V1.8.0/Projects/NUCLEO-WBA55CG/Applications/Zigbee/Zigbee_OnOff_Client_Router_ThreadX/STM32CubeIDE)

The icons show they are Linked Resources, also visible from project properties:

 

[ad101]

Hi Julien,

 

osgi-exporter is on the latest version, 0.0.5.

And I believe the threadx assembly files should be part of the project tree:

 

So I guess it’s just some niche bug then? I didn’t create the project, so I don’t know if there was anything unique about the creation process.

Alex

[Julien D]

Thanks ​@ad101, for your screenshot. It helped a lot in understanding the root cause.

This is only a matter of file extension: the exporter considers only .s files as assembler sources, not .S files.

You can confirm this on your side by simply renaming the assembly sources to *.s.

I created an internal ticket to address this bug. Thanks again for helping improve the robustness of our extensions.