Many strange problems with STM32 projects are caused by combining incompatible versions of those components. E.g. trying to use a newer HAL library with an older hal_conf.h<\/strong> file could result in build errors because the new library would be expecting some macros that are not present in the old file.<\/p>\n Before you begin troubleshooting any STM32-specific errors, ensure you locate each of those components in Solution Explorer and understand where they are physically located:<\/p>\n When you create a regular project with the VisualGDB Embedded Project Wizard, VisualGDB will automatically download a copy of the STM32 library files (including the HAL library) and will store them under %LOCALAPPDATA%\\VisualGDB<\/strong>. Those files will appear inside the Device-Specific Files<\/strong> folder in Solution Explorer. You can use the VisualGDB Project Properties -> Embedded Frameworks<\/strong> to add or remove the VisualGDB-managed copy of the HAL library: When you open the project on a different machine, VisualGDB would automatically download the STM32 BSP (including the HAL library) under %LOCALAPPDATA%, so you won’t need to copy those files along with your project. You can find out the currently installed version of the STM32 BSP via Tools->VisualGDB->Manage VisualGDB Packages<\/strong>: WARNING: <\/strong>Each time you change any target-related settings in VisualGDB Project Properties, the list of files under the Device-Specific files<\/strong> folder will be overwritten. If you would like to manually add new files from the VisualGDB’s BSP to the project, make sure you add them outside the Device-Specific Files<\/strong> folder. If you want to remove some of the files that were automatically added, use the “Excluded From Build<\/strong>” flag instead: If you create the project by cloning one of the STM32CubeMX samples via the VisualGDB Project Wizard, it will not reference the STM32 frameworks via the Embedded Frameworks<\/strong> mechanism. Instead, it will directly include just the files from the original ST sample. They will be located in the Shared sources folder<\/strong> outside Device-specific files<\/strong>: Similarly to the cloned STM32CubeMX samples, the imported projects generated by the STM32CubeMX generator will not reference the regular HAL library. Instead, they will include their own copy of the HAL files and will reference them directly. The only VisualGDB-managed file will be the startup_stm32xxxx.c<\/strong> file containing the interrupt vector table: If you are using VisualGDB Custom Edition or higher, you can convert any regular STM32 project to a stand-alone one. Stand-alone projects include their own copy of all the necessary files in the <ProjectDirectory>\\BSP<\/strong> folder, but are completely detached from the regular STM32 BSP and do not allow referencing any further frameworks: The following table lists the common STM32 project types, along with their advantages and disadvantages:<\/p>\n Most problems with STM32 projects come from using multiple copies of the STM32 HAL (e.g. referencing one via VisualGDB Project Properties -> Embedded Frameworks<\/strong> on top of the one included with the STM32CubeMX project), or by using incompatible versions of components (e.g. using an older configuration file with a newer HAL).<\/p>\n In order to troubleshoot the build problems, make sure you understand which copy of the HAL libraries the project is supposed to use. E.g. if it was generated by STM32CubeMX, ensure it doesn’t reference the VisualGDB-supplied HAL library, or any other libraries. Also creating a new project of the same type from scratch, and comparing it to the broken project may help locating the root cause of the problems.<\/p>\n If nothing helps, try clearing the Additional Include Directories<\/strong> setting:![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/stm32components.png\")
<\/a>You can find the physical location of each file via the Properties window in Solution Explorer:![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/props.png\")
<\/a>Alternatively, you can open the mouse in the VS editor and hover the mouse over its tab header to find out the full path:![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/popup.png\")
<\/a><\/p>\nRegular STM32 Projects<\/h1>\n
<\/a>When you reference the any framework via VisualGDB Project Properties<\/strong> -> Embedded Frameworks<\/strong>, it will do the following:<\/p>\n\n
<\/a>VisualGDB Custom Edition or higher allows installing multiple versions of the same BSP and selecting the version for each project via VisualGDB Project Properties -> Embedded Project<\/strong>.<\/p>\n<\/a>Files excluded from build will remain in Solution Explorer, but will be skipped when building the project. VisualGDB will not overwrite this flag when updating the list of files in Solution Explorer. Note that the flag works independently for each configuration.<\/p>\nCloned STM32CubeMX Samples<\/h1>\n
<\/a>This project type is recommended for quickly exploring the STM32 code samples, however it may require non-trivial changes when upgrading to the newer STM32 BSP, or when trying to reference further libraries via VisualGDB Project Properties -> Embedded Frameworks<\/strong>.<\/p>\nImported STM32CubeMX Projects<\/h1>\n
<\/a><\/p>\nStand-Alone Projects<\/h1>\n
<\/a><\/p>\nProject Type Summary<\/h1>\n
\n\n
\n Project Type<\/td>\n Recommended Use<\/td>\n STM32 HAL Location<\/td>\n Remarks<\/td>\n<\/tr>\n \n Regular<\/td>\n Long-term projects<\/td>\n %LOCALAPPDATA%\\VisualGDB\\<…><\/td>\n Can be relatively easy upgraded to newer STM32 BSP versions.<\/td>\n<\/tr>\n \n Cloned STM32CubeMX Samples<\/td>\n Quickly Exploring STM32 Examples<\/td>\n %LOCALAPPDATA%\\VisualGDB\\<…><\/td>\n Upgrading the STM32 BSP, or referencing new frameworks may require manual changes to the project.<\/td>\n<\/tr>\n \n Imported STM32CubeMX Projects<\/td>\n Long-term projects that require changes via STM32CubeMX.<\/td>\n Per STM32CubeMX Settings<\/td>\n Some Embedded Frameworks may conflict with STM32CubeMX-supplied versions.<\/td>\n<\/tr>\n \n Stand-alone projects<\/td>\n Projects that require patches to the STM32 libraries<\/td>\n <Project Directory>\\BSP<\/td>\n Including a separate copy of the STM32 files with the project considerably increases its size.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Troubleshooting Project Problems<\/h1>\n
<\/a>If you were using VisualGDB header discovery<\/a>, you might have inadvertently added incompatible include directories to the project (e.g. directories from the VisualGDB-supplied STM32 HAL to a project managed by STM32CubeMX, or vice versa).<\/p>\n