Forum Replies Created
-
Posts
-
I could have sworn my VisualGDB auto-updated itself this morning, but it seems that reinstalled the above linked version has fixed the problem. Thanks!
Okay, just another post for posterity; instead of copying the system_stm32f4xx.c file from the STM32 template folder, search for it in the project and remove it, then re-add the version found in the Src folder. That way you don’t have to re-copy it every time you regen the code in CubeMX
The above method causes issues since there can be an alternate cmsis_os.h that is detected
For those looking in the future:
The above suggested method does not work nicely because of the presence of cmsis_os.h in the “Drivers\CMSIS\RTOS\Template” folder. This is added when the “Copy all libraries into the project folder” option is enabled in CubeMX code generation options. This folder can be deleted or the option can be changed to “Copy only the necessary library files”. If the option is changed then arm-eabi-gcc.exe will fail and the contents of “Drivers\CMSIS\Device\ST\STM32F4xx\Source\Templates” folder need to be copied over from the default firmware folder in CubeMX. Also this is alternatively done by removing the “Template” folder from the Include Directories in MSBuild sub menu of the VisualGDB project options and adding the two FreeRTOS directories (see below) containing the correct versions manually.
Once this has been done I was getting errors for undefined references to several function. This was solved by adding the cmsis_os.c and port.c files to the Visual Studio project by right clicking Source Files in project explorer, Add | Existing Item… The files are located in “Middlewares\Third_Party\FreeRTOS\Source\CMSIS_RTOS” and “Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM4F” respectively.
I assume the folder names will change for other ARM cores or ST micros; I was using an STM32F401RE.
I think this is something that could also be improved on from VisualGDB’s side, one way or another!
