Hi!
I've tried all day to make VSCode intellisense work in dual-core environment, but it just doesn't.
Firstly, here is the steps to reproduce:
- Open STM32CubeMX 6.12.1 (latest version as of right now), access MCU selector and select STM32H747BI MCU.
- When asked to apply default configuration - answer yes.
- Go to Connectivity and make UART4 available to both cores (tick both checkboxes) and set mode to Asynchronous (this is to get some files generated under Src/Inc directories in both cores).
- Go to Clock Configurator and fix clocks.
- Go to Project Manager and change toolchain to CMake. Set Project Location and under Code Generation tab on the left, tick "Generate peripheral initialization as a pair of .c/.h files per peripheral".
- Generate code, close CubeMX.
- Open VSCode and select STM32 VSCode Extension icon on the side panel.
- Click Import CMake Project and choose our newly created project path. Import project.
- Open CM7/Src/main.c and includes at the top of the file should look like this:
Why this happens? I don't know, but I have some clues.
If we click on the CMake icon on the side panel, it'll open current CMake configuration. Notice that under Project Outline, there are our two sub-projects for both cores, but there's no source code files attached to them.
If we create project for any of the single-core devices using the same method as above (see reproduction steps), we will get this project outline:
All source files now have working IntelliSense and all includes do resolve without errors.
Looking back into our dual-core project, I've noticed the mx-generated.cmake file under the root of out project. It contains two calls to ExternalProject_Add functions, which includes our sub-projects to root project to successfully build them. But they treat our sub-project as library and don't configure IntelliSense to look into their source/header files - that's why we get include errors.
My suggested fix is that instead of ExternalProject_Add, we can use add_subdirectory function. To test this, modify our mx-generated.cmake file contents to this:
set(ST_MULTICONTEXT DUAL_CORE CACHE STRING "Type of multi-context")
#-----------------------Build CM4 Project-----------------------#
if((${BUILD_CONTEXT} MATCHES .*CM4.*) OR (NOT DEFINED BUILD_CONTEXT))
message(" Build context: CM4")
# Add CM4 project as a subdirectory
add_subdirectory(${PROJECT_SOURCE_DIR}/CM4 ${CMAKE_SOURCE_DIR}/CM4/build)
# Define a build target for the CM4 project
set(ST_DUAL_CORE_CM4_PROJECT_BUILD_TARGET
${CMAKE_SOURCE_DIR}/CM4/build/test-h747bi-vscode_CM4${CMAKE_EXECUTABLE_SUFFIX_CXX}
CACHE FILEPATH "Path to CM4 project target"
)
endif()
#-----------------------Build CM7 Project-----------------------#
if((${BUILD_CONTEXT} MATCHES .*CM7.*) OR (NOT DEFINED BUILD_CONTEXT))
message(" Build context: CM7")
# Add CM7 project as a subdirectory
add_subdirectory(${PROJECT_SOURCE_DIR}/CM7 ${CMAKE_SOURCE_DIR}/CM7/build)
# Define a build target for the CM7 project
set(ST_DUAL_CORE_CM7_PROJECT_BUILD_TARGET
${CMAKE_SOURCE_DIR}/CM7/build/test-h747bi-vscode_CM7${CMAKE_EXECUTABLE_SUFFIX_CXX}
CACHE FILEPATH "Path to CM7 project target"
)
endif()
Now save it and we get this cmake error:
[cmake] Build context: CM4
[cmake] Build type: Debug
[cmake] CMake Error at CM4/CMakeLists.txt:37 (project):
[cmake] The CMAKE_C_COMPILER:
[cmake]
[cmake] arm-none-eabi-gcc
[cmake]
[cmake] is not a full path and was not found in the PATH.
[cmake]
[cmake] Tell CMake where to find the compiler by setting either the environment
[cmake] variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
[cmake] the compiler, or to the compiler name if it is in the PATH.
[cmake]
[cmake]
[cmake] CMake Error at CM4/CMakeLists.txt:37 (project):
[cmake] The CMAKE_CXX_COMPILER:
[cmake]
[cmake] arm-none-eabi-g++
[cmake]
[cmake] is not a full path and was not found in the PATH.
[cmake]
[cmake] Tell CMake where to find the compiler by setting either the environment
[cmake] variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
[cmake] to the compiler, or to the compiler name if it is in the PATH.
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
The dirty fix (haven't brainstormed this one enough) for this error I found is to wrap some lines of gcc-arm-none-eabi.cmake file in the root of our project into if statement:
if(NOT DEFINED STM32_MCU_FLAGS)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc)
set(CMAKE_ASM_COMPILER ${CMAKE_C_COMPILER})
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g++)
set(CMAKE_LINKER ${TOOLCHAIN_PREFIX}g++)
set(CMAKE_OBJCOPY ${TOOLCHAIN_PREFIX}objcopy)
set(CMAKE_SIZE ${TOOLCHAIN_PREFIX}size)
endif()
Now if we save, we get this much better project outline with the source files:
If we visit any source file, we see no errors and we can open any header file by Ctrl-clicking on it and it will open each projects corresponding files (usart.h in CM7 main.c opens CM7 usart.h and the same file in CM4 opens CM4 file).
It will still not build because the path to the linkerscript is wrong now. To fix this, add CMX/ to each of the sub-projects CMakeLists.txt files, as follows:
set(STM32_LINKER_SCRIPT CM7/stm32h747xx_flash_CM7.ld)
set(STM32_LINKER_SCRIPT CM4/stm32h747xx_flash_CM4.ld)
Now the root project and sub-projects successfully builds.
This is A LOT of tinkering just to set up the project with properly working IntelliSense. My guess is that it's the problem in CubeMX CMake generation, because it doesn't care about IntelliSense in IDE's - it just makes build process work. And it works.
I've yet to test the MCU flashing functionality and dual-core debugging. Already a full day wasted on just one basic feature. Not to mention - this should be fixed ASAP. Working without IntelliSense is just like using nano or notepad for writing code - it's definitely possible, but why in 2024?
Hope this post will help somebody.
