2024-09-03 12:03 AM
Am using the dual core STM32H747. A simple project in VScode from STMcubeMX built for CMAKE builds fine but intellisense bad. Becomes confused about which main.h, the one under CM4 or CM7. Have not been able to set up include path to make sense of this. You would think the output from STMcubeMX would work unmodified, but it does not. Could really use some help here.
Solved! Go to Solution.
2024-09-07 01:44 PM
For this I've modified c_cpp_properties.json in .vscode folder to include 2 configurations, one for each core.
To switch between them Ctrl + Shift + P and select "C/C++ Select a configuration..." or click on the bottom right of the vscode status bar. Where the STM32 configuration must be selected by default.
The relevant part is the path to the "compileCommands", that is required by IntelliSense to help with autocompletion.
{
"version": 4,
"configurations": [
{
"name": "STM32",
"configurationProvider": "ms-vscode.cmake-tools",
"intelliSenseMode": "${default}",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
},
{
"name": "CM4",
"compileCommands": "${workspaceFolder}/CM4/build/compile_commands.json",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
},
{
"name": "CM7",
"compileCommands": "${workspaceFolder}/CM7/build/compile_commands.json",
"intelliSenseMode": "${default}",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
}
]
}
Hope it helps you!
2024-09-04 07:39 PM
It seems that this issue is more related to Intellisense rather than CubeMX. CubeMX's role is to generate the necessary boilerplate code to ensure the project builds correctly. We generally do not provide support on the third-party extension themselves.
As for the issue with duplicate file names, I'm not certain if adjusting the c_cpp_properties.json
file would resolve it.
There seem to be ongoing documented issues with this scenario and Intellisense, might be worth a read and follow up on the issue with Microsoft, this is as early as last week.
https://github.com/microsoft/vscode-cpptools/issues/12650
2024-09-07 01:44 PM
For this I've modified c_cpp_properties.json in .vscode folder to include 2 configurations, one for each core.
To switch between them Ctrl + Shift + P and select "C/C++ Select a configuration..." or click on the bottom right of the vscode status bar. Where the STM32 configuration must be selected by default.
The relevant part is the path to the "compileCommands", that is required by IntelliSense to help with autocompletion.
{
"version": 4,
"configurations": [
{
"name": "STM32",
"configurationProvider": "ms-vscode.cmake-tools",
"intelliSenseMode": "${default}",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
},
{
"name": "CM4",
"compileCommands": "${workspaceFolder}/CM4/build/compile_commands.json",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
},
{
"name": "CM7",
"compileCommands": "${workspaceFolder}/CM7/build/compile_commands.json",
"intelliSenseMode": "${default}",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
}
]
}
Hope it helps you!
2024-09-10 09:14 PM
This has been very helpful. I am still hoping for a more complete solution to the problem. It seems to me the code generated by stmcubemx for vscode should at least work correctly as generated. Otherwise what's the point.
Many thanks for your solution as it helps me do the work I need to do now.
Thomas
2024-11-01 12:59 AM
Thanks a lot, this works well with a H7RS (Boot + Appli) project.
{
"version": 4,
"configurations": [
{
"name": "STM32",
"configurationProvider": "ms-vscode.cmake-tools",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"intelliSenseMode": "${default}",
"cStandard": "c17",
"cppStandard": "c++17"
},
{
"name": "Boot",
"compileCommands": "${workspaceFolder}/Boot/build/compile_commands.json",
"intelliSenseMode": "${default}",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
},
{
"name": "Appli",
"compileCommands": "${workspaceFolder}/Appli/build/compile_commands.json",
"intelliSenseMode": "${default}",
"compilerPath": "/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/arm-none-eabi-gcc",
"cStandard": "c17",
"cppStandard": "c++17"
}
]
}
2025-01-09 10:03 AM
My finding is that Intellisense is not working because STM32VSCodeExtension relies on the ExternalProject module to build dual-core projects. I think this module does nothing during CMake configuration and is only triggered during the build process. There are other issues that I don't want to discuss now, but the main one is that it hides from Intellisense which source files are being used.
I reworked the CMake build files to avoid using the ExternalProject module and Intellisense works as expected. Unfortunately this leads to other issues with STM32VSCodeExtension because now the following variables are not being populated: STM32VSCodeExtension.dualCoreCM7Target and STM32VSCodeExtension.dualCoreCM4Target.
I had to edit launch.json to point to the correct .elf files. So, overall I think if the ST team behind the extension decides to remove the dependency on the ExternalProject module, it will solve the problem with Intellisense and dual-core projects.