Skip to main content
GBrow.3
Associate II
February 17, 2022
Solved

Using STM32cubeIDE and FreeRTOS - build Debug can't find cmsis_os.h. Release build completes with no issues.

  • February 17, 2022
  • 3 replies
  • 6512 views

I'm fairly new to STM32CubeIDE having used Keil uV for projects so I'm just not seeing the obvious here.

No issues with build prior to enabling the FreeRTOS for NUCLEO-G474RE development target.

Enable the FreeRTOS and build Release - no issues, completes with no errors.

If I build for Debug (intend to load on Nucleo target using STLink - I get:

../Core/Src/main.c:22:10: fatal error: cmsis_os.h: No such file or directory

  22 | #include "cmsis_os.h"

   |      ^~~~~~~~~~~~

compilation terminated.

I've tried to add project paths to Run/Debug settings but did not change the outcome.

Appreciate the community's help!

STM32CubeIDE

Version: 1.8.0

Build: 11526_20211125_0815 (UTC)

(C) 2021 STMicroelectronics ALL RIGHTS RESERVED

This topic has been closed for replies.
Best answer by Harvey White

OK, I've probably done something close to what you have done.

You can do exactly that, import the ICO file into another project. If you're using an ST board (disco, etc), you may want to set the pin assignments to default, since that tracks the actual board hardware (which is not always the default settings, which can change)

Since you can't have a project with two main.c files (or shouldn't!), it sounds as if when importing the IOC file, you created a new project in the same directory as possibly the old one, or at least, the same workspace.

You might want to check where things are, and remove the older project. Eclipse will allow multiple projects in a workspace, but I tend to avoid it.

A preferred (because it works) structure is to have a directory which has a folder of "subsystems", which contains all the files I use, system files, driver files, specific hardware (I do use an RTOS), categorized as I like.

I have a separate folder at the same level as the subsystems file, called "projects" which contains each particular project workspace. That also contains the main.c and all the other files needed for that project.

To make a new project, I set up a blank folder within projects, then set the workspace to that. I then either generate the IOC file or do a new project based on the IOC file, making sure that the project location created is the newly named file. I add stuff as needed (I do a lot of #ifdef) in an "options.h" file which is in the "core" folder, but not the inc or src (you need to add paths as needed).

Then I can take the entire subsystems folder and drag it from the file manager and drop it on the top level project. Tell the system to create links, rather than copy. Go to the subsystems folder and look at the properties. Make sure the "exclude from build" is NOT checked (don't ask how I found this out). The other files under subsystems should follow this.

Rebuild index as needed. Delete unwanted file links from under subsystems as needed, note that it's all links.

You'll always be working with your original files, not copies, so you need to be careful when making changes to your "standard" files, etc.

Perhaps this will help.

3 replies

Harvey White
Senior III
February 18, 2022

Well, as you know, the project properties have both C and C++ and assembly settings. You'd generally want to have cmsis_os.h in the path for both C and C++. Ditto, you have settings for both debug and "run" scenarios. I'd suggest going through the possibilities in the setups.

Generally, the cmsis_os.h setup is done in actually creating the project, which may suggest that you didn't check all the boxes.

If you were adding anything (and I need to), then when you add a path make sure that it's for all versions and all languages, because it will leave out something useful.

As a further note, sometimes you don't want the C compilere looking at a C++ program segment, so not all the time do you want the same include paths per language.

GBrow.3
GBrow.3Author
Associate II
February 21, 2022

Thanks for your reply Harvey. This is a C/assm only project with no intentional C++ files so that should limit the impacted builds. What may be complicating the issue is some confusion I've created in the project structure as I've been learning this tool. Initially I built the .ico file in one project then imported it to the current project. What I find is there are two main.c files and they seem to be different between release and debug so I'm spending today cleaning up the project directories.

I'll have more to post as I figure this puzzle out

Harvey White
Harvey WhiteBest answer
Senior III
February 21, 2022

OK, I've probably done something close to what you have done.

You can do exactly that, import the ICO file into another project. If you're using an ST board (disco, etc), you may want to set the pin assignments to default, since that tracks the actual board hardware (which is not always the default settings, which can change)

Since you can't have a project with two main.c files (or shouldn't!), it sounds as if when importing the IOC file, you created a new project in the same directory as possibly the old one, or at least, the same workspace.

You might want to check where things are, and remove the older project. Eclipse will allow multiple projects in a workspace, but I tend to avoid it.

A preferred (because it works) structure is to have a directory which has a folder of "subsystems", which contains all the files I use, system files, driver files, specific hardware (I do use an RTOS), categorized as I like.

I have a separate folder at the same level as the subsystems file, called "projects" which contains each particular project workspace. That also contains the main.c and all the other files needed for that project.

To make a new project, I set up a blank folder within projects, then set the workspace to that. I then either generate the IOC file or do a new project based on the IOC file, making sure that the project location created is the newly named file. I add stuff as needed (I do a lot of #ifdef) in an "options.h" file which is in the "core" folder, but not the inc or src (you need to add paths as needed).

Then I can take the entire subsystems folder and drag it from the file manager and drop it on the top level project. Tell the system to create links, rather than copy. Go to the subsystems folder and look at the properties. Make sure the "exclude from build" is NOT checked (don't ask how I found this out). The other files under subsystems should follow this.

Rebuild index as needed. Delete unwanted file links from under subsystems as needed, note that it's all links.

You'll always be working with your original files, not copies, so you need to be careful when making changes to your "standard" files, etc.

Perhaps this will help.

GBrow.3
GBrow.3Author
Associate II
February 21, 2022

Moved to reply not answer.

mattias norlander
ST Employee
February 22, 2022

Are you able to export and attach the project so that we can troubleshoot? Or can you easily produce another project not containing proprietary code but still exhibiting the same error?

GBrow.3
GBrow.3Author
Associate II
February 22, 2022

Thanks for your offer Mattias, but I'd have to run most any code through our legal dept first. I believe I've resolved the initial linker issues following the notes @Harvey White​ offered. That, however, uncovered another puzzle - multiply defined SystemCoreClock, SystemInit and SystemCorClockUpdate due to Drivers\CMSIS ...\Templates and Core\Src both calling system_stm32g4xx.c. I believe this conflict is associated with including the RTOS to the project as I hadn't seen this error prior to enabling the RTOS.

This all appears to be my basic learning curve. I'll post additional request if I am not able to resolve this one quickly.

Regards,

Harvey White
Senior III
February 22, 2022

PLUGH! (nothing happens)

or was that XYZZY?

and the passages were supposed to be "all alike"......

(maybe).

GBrow.3
GBrow.3Author
Associate II
February 22, 2022

Both actually depending on which one you stumbled in to!