Type: Bug Report

Describe the bug

• OS and Version: Windows 10 22H2 (Build 19045.2604)
• VS Code Version: 1.76.1
• Embedded Tools Extension Version: 0.6.0
• Target embedded device: MXChip_AZ3166
• Other extensions you installed (and if the issue persists after disabling them):
  • ms-vscode-remote.vscode-remote-extensionpack
  • mhutchie.git-graph
  • eamodio.gitlens
  • vscode-icons-team.vscode-icons
  • oderwat.indent-rainbow
  • ms-vscode.cpptools-extension-pack
  • twxs.cmake
  • redhat.vscode-yaml
  • jeff-hykin.better-cpp-syntax

The issue persists after disabling the extensions.

• A clear and concise description of what the bug is:

I followed this article to bootstrap my dev environment with vcpkg: https://devblogs.microsoft.com/cppblog/vcpkg-artifacts
First I tried to build the example project all in VS Code with the vcpkg environment activated like described in the article and this worked fine.
Then I changed the extension of main.c to main.cpp and I made a few C++ compatibility changes to the project. You can find the changes in my fork of the getting-started repo (https://github.com/Sn1cket/getting-started/tree/build_with_cpp)
In this state I am able to build the project when I run the following commands in a terminal:

vpckg activate
cmake --preset arm-gcc-cortex-m4
cmake --build --preset arm-gcc-cortex-m4

The problem starts when I try to do the same in VS Code. I am getting the following error when compiling the main.cpp file:

[build] C:\Users\<User>\AppData\Roaming\Code\User\globalStorage\ms-vscode.vscode-embedded-tools\vcpkg\root\downloads\artifacts\vcpkg-ce-default\compilers.arm.gcc\2020.10.0\bin\arm-none-eabi-g++.exe -DJSMN_HEADER -DNX_INCLUDE_USER_DEFINE_FILE -DSTM32F4 -DSTM32F412Rx -DTX_INCLUDE_USER_DEFINE_FILE -DUSE_HAL_DRIVER -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/app/. -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/threadx/ports/cortex_m4/gnu/inc -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/build/lib/threadx/custom_inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/ports/cortex_m4/gnu/inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/common/inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/auto_ip -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/azure_iot -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/BSD -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/cloud -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/dhcp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/dns -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/ftp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/http -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/lwm2m -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/mdns -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/mqtt -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/nat -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/pop3 -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/ppp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/pppoe -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/ptp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/smtp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/snmp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/sntp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/telnet -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/tftp -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/web -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/websocket -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/crypto_libraries/inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/nx_secure/inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/nx_secure/ports -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/build/lib/netxduo/custom_inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/azure_iot/azure-sdk-for-c/sdk/tests/core/inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/azure_iot/azure_iot_security_module -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/azure_iot/azure_iot_security_module/inc -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/azure_iot/azure_iot_security_module/inc/configs/RTOS_BASE -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/netxduo/addons/azure_iot/azure_iot_security_module/iot-security-module-core/inc -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/lib/stm32cubef4/Drivers/CMSIS/Device/ST/STM32F4xx/Include -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/lib/stm32cubef4/Drivers/CMSIS/Include -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/lib/stm32cubef4/Drivers/STM32F4xx_HAL_Driver/Inc -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/lib/stm32cubef4/config -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/lib/mxchip_bsp/stm_sensor/Inc -IE:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/lib/mxchip_bsp/ssd1306 -IE:/dev/projects/vcpkg-playground/getting-started/shared/src/. -IE:/dev/projects/vcpkg-playground/getting-started/shared/src/azure_iot_mqtt -IE:/dev/projects/vcpkg-playground/getting-started/shared/lib/jsmn/src -isystem E:/dev/projects/vcpkg-playground/getting-started/shared/lib/threadx/common/inc -isystem E:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/lib/wiced_sdk/inc -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g3 -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin -fno-common -Wall -Wshadow -Wdouble-promotion -Werror -Wno-unused-parameter -g -MD -MT app/CMakeFiles/mxchip_azure_iot.dir/main.cpp.obj -MF app\CMakeFiles\mxchip_azure_iot.dir\main.cpp.obj.d -o app/CMakeFiles/mxchip_azure_iot.dir/main.cpp.obj -c E:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/app/main.cpp
[build] In file included from c:\users\<User>\appdata\roaming\code\user\globalstorage\ms-vscode.vscode-embedded-tools\vcpkg\root\downloads\artifacts\vcpkg-ce-default\compilers.arm.gcc\2020.10.0\arm-none-eabi\include\c++\10.2.1\stdlib.h:36,
[build]                  from E:/dev/projects/vcpkg-playground/getting-started/shared/lib/threadx/ports/cortex_m4/gnu/inc/tx_port.h:85,
[build]                  from E:/dev/projects/vcpkg-playground/getting-started/shared/lib/threadx/common/inc/tx_api.h:121,
[build]                  from E:/dev/projects/vcpkg-playground/getting-started/MXChip/AZ3166/app/main.cpp:6:
[build] c:\users\david\appdata\roaming\code\user\globalstorage\ms-vscode.vscode-embedded-tools\vcpkg\root\downloads\artifacts\vcpkg-ce-default\compilers.arm.gcc\2020.10.0\arm-none-eabi\include\c++\10.2.1\cstdlib:41:10: fatal error: bits/c++config.h: No such file or directory
[build]    41 | #include <bits/c++config.h>
[build]       |          ^~~~~~~~~~~~~~~~~~
[build] compilation terminated.

It seems like the compiler include paths don't get resolved properly in the VS Code vcpkg environment.

To Reproduce
Steps to reproduce the behavior:

1. Clone this repository https://github.com/Sn1cket/getting-started/tree/build_with_cpp
2. Open MXChip/AZ3166/AZ3166.code-workspace in VS Code
3. Activate the vcpkg environment
4. Open the terminal in VS Code
5. Run cmake --preset arm-gcc-cortex-m4 && cmake --build --preset arm-gcc-cortex-m4
6. See error

Expected behavior
I expect the build to finish like outside of the terminal

Code sample and logs

• https://github.com/Sn1cket/getting-started/tree/build_with_cpp

I see that MS (together with ST) did a great job creating a way to import STCube projects into VSCode.
I'd like having the same feature for Keil uVision .projx projects.

Is there someone else interested in this feature?

Files excluded in .cproject (<entry excluding="foo.c"|"bar.c">) are still included in generated st-project.cmake

Type: Feature Request

Is it possible to use this extension in tandem with cortex-debug https://github.com/Marus/cortex-debug? Cortex debug offers a lot of features im not seeing this tool offering, like RTT output, logging, and plotting. I would like to use this tools FreeRTOS viewer in tandem with cortex-debug.

Maybe It is only me or I am doing something wrong but while I am trying to open STM32 VS Code Extention, I am getting following error:

Cannot activate the 'STM32 VS Code Extension' extension because it depends on the 'Embedded Tools' extension, which is not loaded. Would you like to reload the window to load the extension?

Reloading did not solved the problem.

Extentions are working without problem at local. Having trouble on WSL only.

I checked that embedded tools extension is installed in wsl and it is enabled.

I couldn't find any info about wsl support at market place or at any documentation. Maybe this extention is not wsl supported.

Can you please help me how to make it work on WSL?

The Embedded Tools extension provides a register viewer for CMSIS-SVD files. I've opened svd file, but it has been treated as an ordinary XML. How can I activate alternative view for this file? I mean a sort of SVD editor: https://github.com/dmitrystu/svd_editor

Type: Bug Report

Describe the bug

• OS and Version: Mac os 12.5.1
• VS Code Version: 1.71
• Embedded Tools Extension Version: 0.3.220903001
• Target embedded device:
• RTOS version:
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.

Plugin does not detect STM32CubeIDE but ide was installed. Additionally I cannot select .cproject file - possibility for selecting this file is disabled.

Type: Feature Request

Append path "/opt/ST/STM32CubeCLT/GNU-tools-for-STM32/bin/" into template file gcc-arm-none-eabi.cmake.
It's default installation path for STM32CubeCLT on MacOS.

my test svd：
test.txt
my launch

"svdPath":"./test.svd",

Type: Bug Report

Describe the bug

• OS and Version: Windows 11 22H2 and Macos 13.3.1
• VS Code Version: 1.77.3
• Embedded Tools Extension Version: 0.7.0
• Target embedded device: STM32
• Other extensions : STM32 VS Code Extension

In windows, extension will produce st-project.cmake using \\. Like :

target_sources(
    ${TARGET_NAME} PRIVATE
    "Core\\Src\\freertos.c"
    "Core\\Src\\gpio.c"
    "Core\\Src\\i2c.c"
    "Core\\Src\\main.c"
    "Core\\Src\\rng.c"
    "Core\\Src\\spi.c"
    "Core\\Src\\stm32f4xx_hal_msp.c"
    "Core\\Src\\stm32f4xx_hal_timebase_tim.c"
    "Core\\Src\\stm32f4xx_it.c"
    "Core\\Src\\syscalls.c"
    "Core\\Src\\sysmem.c"
    "Core\\Src\\system_stm32f4xx.c"
    "Core\\Src\\tim.c"
    "Core\\Startup\\startup_stm32f407zetx.s"
    "Middlewares\\ST\\STM32_USB_Device_Library\\Class\\CDC\\Src\\usbd_cdc.c"
    "Middlewares\\ST\\STM32_USB_Device_Library\\Core\\Src\\usbd_core.c"
    "Middlewares\\ST\\STM32_USB_Device_Library\\Core\\Src\\usbd_ctlreq.c"
    "Middlewares\\ST\\STM32_USB_Device_Library\\Core\\Src\\usbd_ioreq.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\CMSIS_RTOS_V2\\cmsis_os2.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\croutine.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\event_groups.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\list.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\portable\\GCC\\ARM_CM4F\\port.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\portable\\MemMang\\heap_4.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\queue.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\stream_buffer.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\tasks.c"
    "Middlewares\\Third_Party\\FreeRTOS\\Source\\timers.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_cortex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_dma_ex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_dma.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_exti.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_flash_ex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_flash_ramfunc.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_flash.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_gpio.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_i2c_ex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_i2c.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_pcd_ex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_pcd.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_pwr_ex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_pwr.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_rcc_ex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_rcc.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_rng.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_spi.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_tim_ex.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal_tim.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_hal.c"
    "Drivers\\STM32F4xx_HAL_Driver\\Src\\stm32f4xx_ll_usb.c"
    "USB_DEVICE\\App\\usb_device.c"
    "USB_DEVICE\\App\\usbd_cdc_if.c"
    "USB_DEVICE\\App\\usbd_desc.c"
    "USB_DEVICE\\Target\\usbd_conf.c"
)

But on macos, \\ causes error in CMake.

[build] CMake Error at CMakeLists.txt:19 (add_executable):
[build]   Cannot find source file:
[build] 
[build]     Core/Src/Core\Src\freertos.c

If I replace "\\" to "/", everything is ok.

• OS and Version: Windows 10 Pro 22H2
• VS Code Version: 1.77.1
• Embedded Tools Extension Version: v0.7.230405001
• Target embedded device: STM32F303RE (Nucleo Board)

Placing a breakpoint somewhere in the code seems to halt the microcontroller, GDB reporting the following in the debug console tab:

ST-LINK_gdbserver: Received Ctrl-C from the client
ST-LINK_gdbserver: Device not halted(0), performing Ctrl-C
ST-LINK_gdbserver: GDB session, device event: 4
ST-LINK_gdbserver: Device halted
ST-LINK_gdbserver: ST-LINK device status: HALT_MODE
ST-LINK_gdbserver: GDB session, device event: 0

VSCode displays the error like this:

Resuming the program works, and the breakpoint is actually applied and reached by the program execution as expected, regardless of all of the warnings and errors displayed when it is set up.

Hi,

I'm really enjoying the embedded tools extension for VSCode so first of all thanks for making it!

The only reason I use STM32CubeIDE now is to view the memory usage build analyser as shown in the picture. It would be great to have a tab that shows that in VSCode.

Kind regards,
Rob

I have STM32CubeIDE installed, and it is the default path used, but the extension still does not find STM32CubeIDE.

Type: Feature Request

Currently the extension only supports viewing zephyr threads, can it support viewing other objects in zephyr?

Allow the sorting of the peripheral registers and the register bit fields by address in addition to sorting by name. Sorting by name may be confusing if one looks a the MCU reference manual.

I added a couple of .c and .h files in a newly created folder, as a custom library, at the same level with Core folder. When running the Create project from ST project command again, the source files are picked up and added to target_sources but the target_include_directories is not updated accordingly, so the build fails. I managed to fix this by creating a separate .cmake file with a function that includes these directory and add the call to that function in CMakeLists.txt.
Would it be possible to update target_include_directories in the st-project.cmake file as well? Or is there a better way of handling such cases?

Type: Bug Report

Describe the bug

• OS and Version: ubuntu&windows10
• VS Code Version: 1.70
• Embedded Tools Extension Version: 0.2.220805001
• Target embedded device: STM32
• RTOS version: RTX5
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Press F5 into debug mode.
2. Press F6 pause when code is running.
3. See error every time.

Expected behavior

It doesn't happen again when I disable Embedded Tools.

Code sample and logs

Undefined command: "_tx_thread_created_ptr".  Try "help".
Undefined command: "pxReadyTasksLists".  Try "help".
Undefined command: "_kernel_thread_info_offsets".  Try "help".

Screenshots

Additional context

Type: Bug Report

OS and Version: Mac os 12.5.1
VS Code Version: 1.71
Embedded Tools Extension Version:v0.3.220909001
Target embedded device: Nucleo F446RE

Description:
When I launch program, I get this error. Next I get information: "ERROR: Unable to start debugging. No process is associated with this object." I'm so confused, because I can open arm-none-eabi-gdb file.

This project seems very promising, but it's not clear if it's heavily developed or not.
Moreover it's not clear if either the community can contribute or it's developed only by MS.

Is it possible to share a roadmap for the development?

Thanks

Hey,

In our team we are working with the MBED framework for embedded development.

MBED is coupled with RTX RTOS, and we would love to work with your extension, which as stated currently supporting FreeRTOS and AzureRTOS only.

Many thanks

Hi. I'm having theses errors when I import my projrct from STM32CubeIDE. I don't know what is need to be done here

Type: Feature Request

Currently the st-project.cmake generated from an stm32cubeide .cproject does not take into account any excluded files.|
These files can be found in the .cproject under

<sourceEntries>
<entry excluding="file1|file2|folderpath" />
</sourceEntries>

Type: Bug Report

• OS and Version: Windows 10
• VS Code Version: 1.70.1
• Embedded Tools Extension Version: 0.2.0
• Target embedded device: STM32WB55
• RTOS version: FreeRTOS 10.2.1
• Other extensions you installed (and if the issue persists after disabling them): IAR Build 1.10.4 and IAR C-SPY Debug 1.10.3

The FreeRTOS tasks of my program are not visible in the Embedded Tools RTOS viewer tab. First, after downloading the program, the tasks list is empty, which is fine since the scheduler has not started yet.

Then, after running the program and pausing it a while after the scheduler has been started, the task list displays the error message "An error occurred while loading details. Make sure the debugger is paused and try again".

My program runs on an STM32WB55 and I'm using the IAR C-SPY debugger with the IAR C-SPY Debug extension for VS code and a STLINK-V3MINI debug probe.

This could also be an issue of the IAR C-SPY Debug extension.

Type: Feature Request

Please display the contents of the peripherals side view in proper columns for register name, value, address, access (r/w) and description and give the user the option to sort the columns and adjust their width.

Type: Feature Request

1. Custom STM32CubeIDE Path

It would be great if there was a setting for this extension to allow us to use a custom path to STM32CubeIDE install location.

I've had to go through and completely uninstall my existing STM32CubeIDE installation and re-install it in the 'default location' because this extension kept on throwing an error and preventing me from running the new (& excellent) STM32 VS Code Extension.

2. Clearer Error Message

It would also be useful if we could make it more obvious that this extension is responsible for the following VSCode error
window popup:

Could not find path to "arm-none-eabi-gdb". Ensure STM32CubeIDE is installed.

As the error popup simply takes you to launch.json, but gives zero indication about which tool is unable to locate arm-none-eabi-gdb.

Type: Bug Report

Describe the bug

• OS and Version: Windows 11
• VS Code Version: 1.76.2
• Embedded Tools Extension Version: 0.7.0
• Target embedded device: STM32F411RE
• A clear and concise description of what the bug is.

I created a simple test project with STM32CubeMX, no code was added to the generated project.

Then, the project was loaded using the STM32 VSCode Extension v1.0.0, the load failed with the following output:

`

Using vcpkg executable at "c:\Users\sidpr.vscode\extensions\ms-vscode.vscode-embedded-tools-0.6.0-win32-x64\assets\platform\win32-x64\vcpkg.exe".
Using VCPKG_ROOT at "c:\Users\sidpr\AppData\Roaming\Code\User\globalStorage\ms-vscode.vscode-embedded-tools\vcpkg\root".
Activating environment at "d:\DataRoot\Projects\MorningClock2\MorningClock_v3_stm32g070KBT\vcpkg-configuration.json".
Version of vcpkg used to create VCPKG_ROOT: "2023-01-24-8a88d63f241d391772fbde69af9cab96c3c64c75".
Running vcpkg with arguments ["version"].
vcpkg package management program version 2023-01-24-8a88d63f241d391772fbde69af9cab96c3c64c75

See LICENSE.txt for license information.

Bundled version of vcpkg: "2023-01-24-8a88d63f241d391772fbde69af9cab96c3c64c75".
Running vcpkg with arguments ["activate","--project","d:\DataRoot\Projects\MorningClock2\MorningClock_v3_stm32g070KBT","--json","C:\Users\sidpr\AppData\Local\Temp\683d8a9626f4c240dfe9f4dd00dd0172"].
warning: vcpkg-ce ('configure environment') is experimental and may change at any time.
read_contents("C:\Users\sidpr\AppData\Roaming\Code\User\globalStorage\ms-vscode.vscode-embedded-tools\vcpkg\root\scripts\vcpkgTools.xml"): no such file or directory
Failed with exit code "1".
Failed to activate environment at "d:\DataRoot\Projects\MorningClock2\MorningClock_v3_stm32g070KBT\vcpkg-configuration.json".`

Type: Bug Report

Describe the bug

• OS and Version: MacOS 12.4
• VS Code Version: 1.69.2
• Embedded Tools Extension Version: v0.1.220728001
• Target embedded device: STM32F429ZI
• RTOS version: FreeRTOS. don't know the version
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.

Several issues with memory views/windows launched from the RTOS view. Most of them are probably inherent to core VSCode, but I wanted to highlight some that can be perhaps be addressed (or forwarded) here.

• They are never updated. They seem to be a static snapshot. This would be very unexpected of a memory view even if the intent was different. The expectation would be that it updates whenever the session pauses at minimum
• The memory views/windows created demand too much memory. On embedded devices, this can be a problem
  • Some devices are not big. They can have errors in reading memory. Asking for 1-2K is enough
  • If/when memory views are updated upon a pause, it will be bad for performance and UX. Once such a large gdb request is made, it cannot be aborted and further instructions will block. Makes single stepping intolerable

To Reproduce
Steps to reproduce the behavior:

1. In your launch.json, add the enable engine logging as shown below for cppdbg

            "logging": {
                "engineLogging": true,
                ...
            },

2. Launch any debug session, run and pause until an RTOS is displayed by this extension
3. Click on any link in the RTOS view that will open a memory view. I use one of the stack pointers. You will notice in the debug console that a read memory request is made for 128KB (131072 bytes). Here are all the memory reads

1: (480376) <-1171-data-read-memory-bytes 0x2000657c 131072

4. Single step in any way until you get back into a paused state
5. You will notice in the Debug Console that if no new memory requests were made. I can change memory contents manually using gdb/programmatically and this window never refreshes
6. FYI: Same applies if you launch the memory viewer from anywhere -- as in Watch/Variable panels.

Expected behavior

• Any memory views created should be updated just like how Watch/Variable windows are updated. Including REPL. Memory windows are supposed to be alive. They should have a lifecycle of their own.
• I did notice that clicking on the link again will refresh the display, no one would know that
• Please don't read 128KB. 1-2KB is enough, updated with scrolling -- like how disassembly works
• Memory views should be persistent. What an embedded developer expects The lifecycle of these memory windows should be re-thought.

Code sample and logs

• Code sample
• launch.json
• Logs from the Embedded Tools Output Window
• Logs from the Debug Console

Screenshots

Additional context
I can duplicate all this with the Cortex-Debug debugger as well.

Maybe I am doing something wrong.

Pop-up error window Could not find path to "arm-none-eabi-gdb". Ensure STM32CubeIDE is installed.

I'm (very) new to VS code and I'm trying to follow https://devblogs.microsoft.com/cppblog/importing-st-projects-into-visual-studio-code/ on Linux.

When I run Create project from ST project a dialog opens, but it refuses to accept the directory containing my .cproject file.

When I click "Open Project" the dialog just enters the Test subdirectory.

The .cproject file IS there...

skip@Dell-5510:~/localref/nexus_charger_led$ ll
total 216
drwxrwxr-x 11 skip skip  4096 Dec 30 12:07  ./
drwxrwxr-x  5 skip skip  4096 Dec 30 12:04  ../
-rw-rw-r--  1 skip skip   928 Dec 17 12:52 'CHARGER_LED_BOARD_Full_System_Test_Build_rev00_08_00_date060622 Debug.cfg'
drwxrwxr-x  3 skip skip  4096 Dec 17 12:52  Configuration/
drwxrwxr-x  5 skip skip  4096 Dec 17 12:52  Core/
-rw-rw-r--  1 skip skip 30589 Dec 17 12:52  .cproject
drwxrwxr-x  2 skip skip  4096 Dec 17 12:52  Doc/
drwxrwxr-x  6 skip skip  4096 Dec 17 12:52  Drivers/
-rw-rw-r--  1 skip skip  9003 Dec 17 12:52  DVT1_Build_Charger_Tower_LED_Board_ver_03_00_01.launch
-rw-rw-r--  1 skip skip  9253 Dec 17 12:52 'DVT1_Build_Charger_Tower_LED_Board_ver_03_00_02E Debug.launch'
-rw-rw-r--  1 skip skip  9247 Dec 17 12:52 'EVT2_Build_Charger_Tower_LED_Board_ver_02_03_01 Debug.launch'
drwxrwxr-x  8 skip skip  4096 Dec 17 12:52  .git/
-rw-rw-r--  1 skip skip     8 Dec 17 12:52  .gitignore
drwxrwxr-x  3 skip skip  4096 Dec 17 12:52  Middlewares/
-rw-rw-r--  1 skip skip 15421 Dec 17 12:52  .mxproject
-rw-rw-r--  1 skip skip  8736 Dec 17 12:52 'nexus_charger_led Debug.launch'
-rw-rw-r--  1 skip skip 12477 Dec 17 12:52  nexus_charger_led.ioc
-rw-rw-r--  1 skip skip  1253 Dec 17 12:52  .project
drwxrwxr-x  2 skip skip  4096 Dec 17 12:52  .settings/
-rw-rw-r--  1 skip skip  4833 Dec 17 12:52  STM32G0B1KBUX_FLASH.ld
-rw-rw-r--  1 skip skip  4824 Dec 17 12:52  STM32G0B1KBUX_RAM.ld
drwxrwxr-x  9 skip skip  4096 Dec 17 12:52  Tasks/
drwxrwxr-x  3 skip skip  4096 Dec 17 12:52  Test/
skip@Dell-5510:~/localref/nexus_charger_led$

• OS and Version:

skip@Dell-5510:~/localref/nexus_charger_led$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

• VS Code Version:

Version: 1.74.2
Commit: e8a3071ea4344d9d48ef8a4df2c097372b0c5161
Date: 2022-12-20T10:27:19.253Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Linux x64 5.15.0-56-generic
Sandboxed: No

• Embedded Tools Extension Version:

• Target embedded device: N/A ... didn't get that far but it's an stm32g0

• RTOS version: n/a

To Reproduce
Try to import ST project on Linux.

Expected behavior
Project imports correctly.

Type: Bug Report

Description
In AzureRTOS, when calling either tx_thread_priority_change or tx_thread_sleep the RTOS Viewer stops being able to get thread information, instead showing "An error occurred while loading details. Make sure the debugger is paused then try again" until the system is restarted, at which point it is again able to see thread information.

In tx_thread_priority_change the specific line that causes the issue is:
thread_ptr -> tx_thread_state = TX_PRIORITY_CHANGE;
I am consistently able to see information in the view before, but not after running this line.

In tx_thread_sleep the bug is inconsistent, sometimes resulting in an error but sometimes working as intended.
After this point until I restart only the "Byte Tool" view is working as intended.

• OS and Version: Darwin arm64 22.2.0
• VS Code Version: 1.74.3 for arm64 Mac
• Embedded Tools Extension Version: v0.5.230126001 Pre-release preview
• Target embedded device: STM32F767NI
• RTOS version: Azure RTOS for STM32F7 Series (1.1.0)
• Debugger: J-LINK EDU 11.0
• Other extensions you installed (and if the issue persists after disabling them):
  • coretex-debug
  • MemoryView
  • RTOS Views
  • Disabling them is not an option as they are required for debugging

To Reproduce

• Setup and create a thread in MX_ThreadX_Init
• In that new thread try to lower/Users/anthony/FusionBiotec/FastPCR/fred-firmware/launch.json its priority by calling tx_thread_priority_change or try sleeping by calling tx_thread_sleep

Expected behavior
The RTOS Viewer continues to display information after a priority change or sleep.

Note: launch.json has been modified to hide the cwd and executable.
launch.json.txt

Type: Feature Request

Hello! I noticed that the extension currently has RTOS data viewer for Azure RTOS & FreeRTOS. It would be great to see support for the Zephyr RTOS as well. It is a very active open source RTOS under the Linux Foundation, with over 1K contributors, and increasingly growing in popularity. FWIW, OpenOCD has supported Zephyr since last year.

I'm not sure what's needed in order to add Zephyr support, but I'm happy to connect anyone from the MSFT team with the relevant folks on the Zephyr side.

Type: Bug Report

• Target embedded device: STM32H757

system_stm32h7xx_dualcore_boot_cm4_cm7.c doesn't get added to st-project.cmake

I didn't find a detailed usage of the tool. But I found a configuration using OpenOCD in issues #3. I tried modifying the configuration to use JLinkGDBServer and the tool seems to work, but I can't control the debug operation.

{
    "name": "Launch",
    "type": "cppdbg",
    "request": "launch",
    "program": "${workspaceFolder}/build/demo743.elf",
    "cwd": "${workspaceFolder}",
    "MIMode": "gdb",
    "miDebuggerPath": "C:/GNU Tools Arm Embedded/7 2018-q2-update/bin/arm-none-eabi-gdb.exe",
    "miDebuggerServerAddress": "localhost:2331",
    "debugServerPath": "C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe",
    "debugServerArgs": "-if SWD -device STM32H743II",
    "svdPath": "${workspaceFolder}/STM32H743x.svd",
    "stopAtConnect": true
}

Can you tell me if the tool does not support JLinkGDBServer or how should I modify the configuration?

Thanks!

Type: Bug Report

Describe the bug

• OS and Version: macOS 12.5.1
• VS Code Version: 1.71.2
• Embedded Tools Extension Version: 0.3.0
• Target embedded device: STM32F07ZG
• RTOS version: Azure RTOS 6.1.12
• Other extensions you installed (and if the issue persists after disabling them): Cortex-Debug 1.6.5

When debugging with Cortex-Debug the RTOS Viewer does not load the 'Threads' details. Some communication is working, as I can see Cortex-Debug is receiving the thread names to display in the Call Stack, however the RTOS Viewer fails to load with "An error occurred while loading details. Make sure the debugger is paused and try again."

I'll note that when I view other elements such as Mutexes/Queues/Timers/etc the view loads correctly and I can see the expected output. Switching the view back to Threads once again gives the same error.

To Reproduce
Steps to reproduce the behavior:

1. Start a Cortex-Debug session.
2. Run the application long enough for the RTOS to initialise the threads.
3. Hit a breakpoint or click Pause.
4. Click Embedded Tools: RTOS Viewer tab.
5. See error.

Expected behavior
RTOS Viewer successfully loads the Threads view.

Code sample and logs

• Logs from the Embedded Tools Output Window: embedded-tools.log
• launch.json settings:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Build & Debug Elf",
            "cwd": "${workspaceRoot}",
            "executable": "${workspaceFolder}/build/debug/<REDACTED_FILENAME>.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "interface": "swd",
            "device": "STM32F407ZG",
            "preLaunchTask": "buildScons",
            "rttConfig": {
              "enabled": true,
              "address": "auto",
              "decoders": [
                  {
                      "port": 0,
                      "type": "console"
                  }
              ]
            },
            "rtos": "Azure",
            "svdPath": "${workspaceFolder}/library/mcal/bsp/STM32F4xxxx/DeviceDefinitions/STM32F407.svd"
        }
    ]
}

Any help is greatly appreciated :)

Type: Bug Report

Describe the bug

• OS and Version: Windows 10 Pro, version 21H2, OS build 19044.1586
• VS Code Version: 1.66.0
• Embedded Tools Extension Version: v0.1.0 Preview
• Target embedded device: Maxim MAX32666GWPBT+T
• RTOS version: FreeRTOS v10.2.0
• Other extensions you installed (and if the issue persists after disabling them): Arm Assembly, Better C++ Syntax, C/C++, C/C++ Extension Pack, C/C++ Themes, C#, Diff Folders, Doxygen Documentation Generator, ESLint, GitHub Repositories, GitLens, Hex Editor, LinkerScript, Pylance, Python, Remote - Containers, Remote - SSH, Remote - SSH: Editing Configuration FIles, Remote - WSL, Visual Studio IntelliCode
• A clear and concise description of what the bug is.

The problem is that the embedded register "peripheral view" is not initializing correctly.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

The peripheral view should initialize.

Code sample and logs

• Code sample
• launch.json:
  { "configurations": [ { "name": "GDB", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/${config:target}.elf", "args": [], "stopAtEntry": true, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "linux": { "miDebuggerPath": "${config:MAXIM_PATH}/Tools/GNUTools/bin/arm-none-eabi-gdb" }, "windows": { "miDebuggerPath": "${config:MAXIM_PATH}/Tools/GNUTools/bin/arm-none-eabi-gdb.exe" }, "miDebuggerArgs": "./build/${config:target}.elf", "preLaunchTask": "flash", "setupCommands": [ { "description": "Launch OpenOCD from within GDB via pipe connection", "text": "target remote | openocd -c \"gdb_port pipe;log_output openocd.log\" -s ${config:MAXIM_PATH}/Tools/OpenOCD/scripts -f interface/${config:debugger}.cfg -f target/${config:target}.cfg", "ignoreFailures": false }, { "description": "Reset", "text": "monitor reset halt", "ignoreFailures": false } ], "svdPath": "${workspaceFolder}/src/MaximSDK/Libraries/CMSIS/Device/Maxim/MAX32665/Include/max32665.svd" }, ] }
• Logs from the Embedded Tools Output Window
  I removed a sensitive portion of path, replaced it with "workingFolder". I also removed the svdString, which is just a printout of the svd file.
  022-04-04T19:00:59.813Z [info] [vscode-embedded] Activating extension 2022-04-04T19:01:29.286Z [debug] [vscode-embedded.webview.registerView] VsCodeHostAdapter [webview -> host]: {"type":"initializeRegisterViewer","messageId":0} 2022-04-04T19:01:29.287Z [debug] [vscode-embedded] Active debug session {"name":"GDB","type":"cppdbg","id":"3b4a5151-385f-4146-9c72-189df9b82350","configuration":{"name":"GDB","type":"cppdbg","request":"launch","program":"workingFolder/build/MAX32665.elf","args":[],"stopAtEntry":true,"cwd":"workingFolder","environment":[],"externalConsole":false,"MIMode":"gdb","miDebuggerArgs":"./build/MAX32665.elf","preLaunchTask":"flash","setupCommands":[{"description":"Launch OpenOCD from within GDB via pipe connection","text":"target remote | openocd -c \"gdb_port pipe;log_output openocd.log\" -s C:/MaximSDK/Tools/OpenOCD/scripts -f interface/cmsis-dap.cfg -f target/MAX32665.cfg","ignoreFailures":false},{"description":"Reset","text":"monitor reset halt","ignoreFailures":false}],"svdPath":"workingFolder/src/MaximSDK/Libraries/CMSIS/Device/Maxim/MAX32665/Include/max32665.svd","__configurationTarget":5,"miDebuggerPath":"C:/MaximSDK/Tools/GNUTools/bin/arm-none-eabi-gdb.exe"}} 2022-04-04T19:01:29.300Z [debug] [vscode-embedded] Workspace configuration {"configuration":{"loggingVerbosity":"debug"}} 2022-04-04T19:01:29.377Z [warn] [vscode-embedded.webview.registerView] String substitution is not supported VsCodeHostAdapter [webview <- host]: {"type":"initializeRegisterViewer","messageId":0,"payload":{"svdString":"...","localization":{"displayLanguage":"en","displayLanguageKind":"VSCode"},"loggingSeverity":"debug"} 2022-04-04T19:01:29.419Z [debug] [vscode-embedded.webview.registerView] Initialized logging 2022-04-04T19:01:29.419Z [debug] [vscode-embedded.webview.registerView] Initializing localization 2022-04-04T19:01:29.420Z [debug] [vscode-embedded.webview.registerView] Loading resources from lang=en-US, ns=resources 2022-04-04T19:01:29.420Z [debug] [vscode-embedded.webview.registerView] Loading resources from lang=en, ns=resources 2022-04-04T19:01:29.420Z [debug] [vscode-embedded.webview.registerView] set register view display language: lang=en, code=VSCode 2022-04-04T19:01:29.550Z [error] [vscode-embedded.webview.registerView] Failed to initialize register view {}
• Logs from the Debug Console

Screenshots

Additional context

Attached file is the contents of max32665.svd:
max32665.txt

Type: Feature Request

Type: Bug Report

Describe the bug

• OS and Version - Windows 10:
• VS Code Version - 1.76.0:
• Embedded Tools Extension Version - v0.6.0:
• Target embedded device - STM32F405:

Hello! At the final make step:
[build] [50/50] Linking C executable prj_upm_01.elf

I get an error:

[build] FAILED: prj_upm_01.elf
....
[build] arm-none-eabi-gcc.exe: error: ../../libSTM32F4XX.a: No such file or directory
[build] arm-none-eabi-gcc.exe: error: ../../libkernel_m4f.a: No such file or directory
[build] arm-none-eabi-gcc.exe: error: ../../libmodbus_rtu_m4f.a: No such file or directory
[build] arm-none-eabi-gcc.exe: error: ../../libuip_m4f.a: No such file or directory
[build] arm-none-eabi-gcc.exe: error: ../../libIQmathLib-cm4f.a: No such file or directory
[proc] The command: c:\Users\Ivan\AppData\Roaming\Code\User\globalStorage\ms-vscode.vscode-embedded-tools\vcpkg\root\downloads\artifacts\vcpkg-ce-default\tools.kitware.cmake\3.20.1\bin\cmake.EXE --build C:/mexbiosdevelopmentstudio_ll_stm32cubeide/.../Libraries/STM32F4XX/prj_upm_01/build/debug/build --target prj_upm_01 exited with code: 1
[build] ninja: build stopped: subcommand failed.
[build] Build finished with exit code 1

Project in Cube IDE makes fine, somehow extension can't find those static libs. Any ideas?

Cproject file in attachments (I couldn't download .cproject, so it in txt format)

cproject.txt

Type: Feature Request

I have not tried the extension yet, but one missing feature I do not see in the presentation is the Memory Viewer (and I don't know extension of VSCode proposing this).

This would be a great feature to permit viewing/editing the memory. IDEs from almost all MCU vendors proposes this feature since a long time.

Type: Feature Request

It would be nice to have a Serial monitor that can connect to a TCP/IP pipe and perform a 2 way communication over the network. This would help people doing remote debugging.

Type: Feature Request

While we can view running threads with this extension, it would be great to view freeRTOS running timers too.

Type: Bug Report

Describe the bug

• OS and Version:
• VS Code Version:
• Embedded Tools Extension Version:
• Target embedded device:
• RTOS version:
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

Code sample and logs

• Code sample
• launch.json
• Logs from the Embedded Tools Output Window
• Logs from the Debug Console

Screenshots

Additional context

Type: Bug Report

Describe the bug

• OS and Version: Windows 10 21H2
• VS Code Version: 1.75.1
• Embedded Tools Extension Version: 0.6.0

To Reproduce
Steps to reproduce the behavior:
Download your example project:
https://github.com/azure-rtos/getting-started
Open following folder:
STMicroelectronics/B-L4S5I-IOT01A
Wait for the integrated vcpkg to activate the project.
Build

Expected behavior
No errors

Code sample and logs
[build] [1/1294] Building C object lib/threadx/CMakeFiles/threadx.dir/common/src/tx_thread_info_get.c.obj [build] FAILED: lib/threadx/CMakeFiles/threadx.dir/common/src/tx_thread_info_get.c.obj [build] C:\Users\Abcdefghijk.Lmnopqrs\AppData\Roaming\Code\User\globalStorage\ms-vscode.vscode-embedded-tools\vcpkg\root\downloads\artifacts\vcpkg-ce-default\compilers.arm.gcc\2020.10.0\bin\arm-none-eabi-gcc.exe -DTX_INCLUDE_USER_DEFINE_FILE -IC:/code/getting-started/shared/lib/threadx/ports/cortex_m4/gnu/inc -Ilib/threadx/custom_inc -isystem C:/code/getting-started/shared/lib/threadx/common/inc -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g3 -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin -fno-common -Wall -Wshadow -Wdouble-promotion -Werror -Wno-unused-parameter -O0 -std=gnu99 -MD -MT lib/threadx/CMakeFiles/threadx.dir/common/src/tx_thread_info_get.c.obj -MF lib\threadx\CMakeFiles\threadx.dir\common\src\tx_thread_info_get.c.obj.d -o lib/threadx/CMakeFiles/threadx.dir/common/src/tx_thread_info_get.c.obj -c C:/code/getting-started/shared/lib/threadx/common/src/tx_thread_info_get.c [build] In file included from C:/code/getting-started/shared/lib/threadx/ports/cortex_m4/gnu/inc/tx_port.h:85, [build] from C:/code/getting-started/shared/lib/threadx/common/inc/tx_api.h:121, [build] from C:/code/getting-started/shared/lib/threadx/common/src/tx_thread_info_get.c:28: [build] c:\users\Abcdefghijk.Lmnopqrs\appdata\roaming\code\user\globalstorage\ms-vscode.vscode-embedded-tools\vcpkg\root\downloads\artifacts\vcpkg-ce-default\compilers.arm.gcc\2020.10.0\arm-none-eabi\include\stdlib.h:10:10: fatal error: machine/ieeefp.h: No such file or directory [build] 10 | #include <machine/ieeefp.h> [build] | ^~~~~~~~~~~~~~~~~~ [build] compilation terminated.

Additional context
Too long file path?
C:\Users\Abcdefghijk.Lmnopqrs\AppData\Roaming\Code\User\globalStorage\ms-vscode.vscode-embedded-tools\vcpkg\root\downloads\artifacts\vcpkg-ce-default\compilers.arm.gcc\2020.10.0\arm-none-eabi\include\machine\ieeefp.h
Already mention it in the issue microsoft/vcpkg#29815 , but it should be a new issue.
Possible solution: enable to move the vcpkg root directory

We would like to extract the vcpkg artifacts support into its own VSCode extension and repo, so that other extensions can take a dependency on it easier and get vcpkg artifacts support.

I can't find a documentation or user guide on this extension anywhere.
I tried to use it with some Zephyr samples (the canonical blinky) but nothing showed up (no relative buttons on the sidebar, no associated command when pressing Ctrl+Shift+P, no information on the bottom status bar)
I'm surely missing something

My setup:
Windows 10
C/C++ extension installed
All Zephyr stuff (zephyr base, SDK, west tool and python packages) installed
An ST Nucleo F401RE connected with drivers installed

When generating Touchgfx projects for dual core boards such as STM32H745i disco, the .cproject file for the CM7 processor contains include paths of the form

<listOptionValue builtIn="false" value="&quot;${workspace_loc:/Drivers/BSP/Components/Common}&quot;"/>

These end up in st-project,cmake as "$<$<AND:$<CONFIG:Debug>,$<COMPILE_LANGUAGE:ASM>>:${PROJECT_SOURCE_DIR}/build\\${workspace_loc:\\Drivers\\BSP\\Components\\Common}>"
which is a syntax error.

Now, it is not clear why the STM tools add the include path, it seems completely unnecessary as the .cproject also contains the include path
"../../../Drivers/BSP/Components/Common"/>
which is the same. I delete the offending lines from st-project.cmake and everything works, but after every modification in Touchgfx they show up again which quickly gets old ;-)

Generating the "Blank UI" example for STM32H745i disco and importing STM32CubeIDE\CM7\.cproject into VS Code reproduces the error. There is no problem with single core boards, only dual core ones.

I am trying to import my ST project into VS Code, I have followed all the steps in the blog I saw on Facebook, however I am getting that error when I run the debug command

I am not entirely sure what the issue is, but I am hoping that you can give me some pointers. My code is building successfully in CubeIDE
cproject.zip
st-project.zip
I have attached my cmake file and also my cproject file.

Brief Issue Summary

The CMakeTools extension is scanning for kits on startup of any CMake project I open in VS Code. This scanning is interfering with proper configuration of the project I opened. I have to wait for the scan to complete and then clean reconfigure. It is unreasonable to think that I have installed a compiler in the time I closed one project and opened another.

Please place some limit on how often kits are scanned for, daily or weekly seems more appropriate. It also does not seem like something that needs to be done on startup if I already have kits configured. This would be far better as a background task.

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

No response