Dual Core STM32CubeMX project includes search path

[cubeit2123]

I created an STM32CubeMX solution targeting a STM32H7 dual core processor. This creates four projects: BSP_CMx and MyProj_CMx.

VisualGDB stuck the STM32CubeMX files in the BSP projects. I put code in the MyProj_ projects. What is the right way to break out of the BSP’s user code? I added source and headers to the MyProj, but I can’t #include them in the USER CODE sections in the BSP. It says “No such file or directory.” VisualGDB seems to recognize this, and the auto header discover stuff pops up when I’m in that file.

So I click “Add to Project Properties…”, and can add it to MyProj_CM7, which solves the error in those source files, but I can’t resolve the error in the BSP_CM7 project. “Add to Project Properties” gives me the option to add the search path to BSP_CM7, but then I get an error from cmake:

” Cannot specify include directories for target “BSP” which is not built by this project.”

[support]

Hi,

VisualGDB follows the project structure set by the STM32CubeMX generator, placing all files generated by it (including the main one) into the BSP library, and the user-added files directly into the executable.

As the executables and the BSP libraries are defined in different CMake targets, they have different sets of settings (executables inherit the settings from the BSP libraries) controlled by CMake statements like target_include_directories(). Editing various settings via GUI ultimately generates one or more CMake statements and has exactly the same affect as if these statements were added manually.

Based on the description you provided, you ended up with a set of target_include_directories() statements that do not match the actual targets. The easiest way to troubleshoot it would be to double-check what statements got added to CMakeLists.txt files. If they reference incorrect BSP names (see the find_bsp() statements), you can simply adjust them manually by editing the CMakeLists.txt file. If you can confirm that VisualGDB consistently generates invalid statements in some cases and can share the steps to reproduce the issue we should be able to fix it. Otherwise, simply patching the generated statement manually should work fine as well.

You can read more about CMake targets and how VisualGDB handles them here: https://visualgdb.com/documentation/projects/cmake/

[Author]

Posts