- This topic has 9 replies, 3 voices, and was last updated 1 year, 7 months ago by
.
-
Posts
-
I’m trying to follow the tutorial for setting up a STM32 with FreeRTOS with CubeMX and VisualGDB but something isn’t working. I am using a Nucleo STM32F401RE board and following the tutorial linked below. Up to step 9, the import process work as described. Enabling FreeRTOS is where the process breaks down. Instead of Enabled/Disabled, the options are CMSIS_V1 or _V2.
Enabling CMSIS_V1 gives the following errors:
Error [Clang IntelliSense] Error: use of undeclared identifier 'osThreadDef' test C:\Users\X\Documents\CubeMX\test\Src\main.c 120
Error [Clang IntelliSense] Error: too many arguments provided to function-like macro invocation test C:\Users\X\Documents\CubeMX\test\Src\main.c 120
Error [Clang IntelliSense] Error: use of undeclared identifier 'os_thread_def_defaultTask' test C:\Users\X\Documents\CubeMX\test\Src\main.c 121
Error cmsis_os.h: No such file or directory test C:\Users\X\Documents\CubeMX\test\Src\main.c 23
Error cmsis_os.h: No such file or directory test C:\Users\X\Documents\CubeMX\test\Src\stm32f4xx_it.c 24
Enabling CMSIS_V2 gives the following errors:
Error cmsis_os.h: No such file or directory test C:\Users\X\Documents\CubeMX\test\Src\main.c 23
Error [Clang IntelliSense] Error: unknown type name 'osThreadId_t'; did you mean 'osThreadId'? test C:\Users\X\Documents\CubeMX\test\Src\main.c 48
Error [Clang IntelliSense] Error: unknown type name 'osThreadAttr_t'; did you mean 'osThreadDef_t'? test C:\Users\X\Documents\CubeMX\test\Src\main.c 122
Error [Clang IntelliSense] Error: use of undeclared identifier 'osPriority_t' test C:\Users\X\Documents\CubeMX\test\Src\main.c 124
Warning [Clang IntelliSense] Warning: incompatible integer to pointer conversion assigning to 'osThreadId' (aka 'struct os_thread_cb *') from 'int' test C:\Users\X\Documents\CubeMX\test\Src\main.c 127
Warning [Clang IntelliSense] Warning: implicit declaration of function 'osThreadNew' is invalid in C99 test C:\Users\X\Documents\CubeMX\test\Src\main.c 127
Error cmsis_os.h: No such file or directory test C:\Users\X\Documents\CubeMX\test\Src\stm32f4xx_it.c 24
Any insight would be appreciated…
https://visualgdb.com/tutorials/arm/stm32/cube/
Hi,
It looks like the STM32CubeMX tool did not include some of the headers or include search paths in the generated .gpdsc file, so VisualGDB did not pick it up.
As a workaround, please try locating the cmsis_os.h file manually using VisualGDB’s header discovery feature as shown here: https://visualgdb.com/tutorials/intellisense/headers/
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!
Thanks for clarifying this. Normally, VisualGDB should automatically pick up the header and source file locations from the GPDSC file, although in our experiments the STM32CubeMX tool can intermittently omit some of them, depending on the project settings and the tool version.
Based on the behavior you described, the GPDSC file was missing multiple FreeRTOS-related components; in that case it could be easier to add reference to FreeRTOS via VisualGDB Project Properties -> Embedded Frameworks.
Please also feel free to attach the generated project (as long as you are using the latest STM32CubeMX release) so that we could recheck if we could update the VisualGDB to extract the correct FreeRTOS component paths.
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
Hi,
We have recently finished investigating this and added logic for automatically correcting invalid file references. Please try this build: VisualGDB-5.4.111.3240.msi
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!
Sorry, this fix isn’t a part of the official release yet, as we will be bundling it together with a few other small improvements. We expect to release the updated version in the end of this week, or the beginning of the next one.
Hello. Has this been fully resolved as I’m getting similar issues?
I get this whether I use cMake or MSBuild
ThanksError [Clang IntelliSense] Error: unknown type name 'osThreadId_t'; did you mean 'osThreadId'? Ex4_cMX_USRT2_fRTOS_MSbuild Error [Clang IntelliSense] Error: unknown type name 'osThreadAttr_t'; did you mean 'osThreadDef_t'? Ex4_cMX_USRT2_fRTOS_MSbuild Error [Clang IntelliSense] Error: use of undeclared identifier 'osPriority_t' Ex4_cMX_USRT2_fRTOS_MSbuild Error [Clang IntelliSense] Error: unknown type name 'osThreadId_t'; did you mean 'osThreadId'? Error [Clang IntelliSense] Error: unknown type name 'osThreadAttr_t'; did you mean 'osThreadDef_t'? Ex4_cMX_USRT2_fRTOS_MSbuild Error [Clang IntelliSense] Error: use of undeclared identifier 'osPriority_t' Ex4_cMX_USRT2_fRTOS_MSbuild Warning [Clang IntelliSense] Warning: incompatible integer to pointer conversion assigning to 'osThreadId' (aka 'struct os_thread_cb *') from 'int' Ex4_cMX_USRT2_fRTOS_MSbuild Warning [Clang IntelliSense] Warning: implicit declaration of function 'osThreadNew' is invalid in C99 Ex4_cMX_USRT2_fRTOS_MSbuild Warning [Clang IntelliSense] Warning: incompatible integer to pointer conversion assigning to 'osThreadId' (aka 'struct os_thread_cb *') from 'int' Ex4_cMX_USRT2_fRTOS_MSbuild
Error MSB4181 The “GCCCompile” task returned false but did not log an error. Ex4_cMX_USRT2_fRTOS_MSbuild C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\gcc.targets 319
The original issue has been resolved a long time ago, so this is likely something different.
Generally, STM32CubeMX sometimes misses some sources or headers when generating project templates. Newer versions of STM32CubeMX often fix such issues, but sometimes introduce new cases.
The best idea to troubleshoot it is to specifically look for header files defining the missing symbols, and then trace it down:
- Is the header file included via #include<>?
- If yes, but the header file is not found, does the include search path contain the header file’s directory?
- Are the definitions conditional to a #define that is not defined?
If you can narrow it down to a specific construct in the generated STM32CubeMX file that was not imported correctly, we should be able to fix the importing logic to handle it properly. If not, please consider editing the sources manually to include the necessary parts.
- You must be logged in to reply to this topic.