cancel
Showing results for 
Search instead for 
Did you mean: 

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

GBrow.3
Associate II

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

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

11 REPLIES 11
Harvey White
Senior III

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
Associate II

Moved to reply not answer.

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

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.

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?

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,

I shouldn't be laughing, but that little bug is one that I've been dealing with for years. ST is currently looking into it.

It happens when you use CubeMXIDE, but apparently not CubeMX.

It's a duplicate file under the following path:

Drivers\device\st\(processor name)\Source\Templates.

It's a copy of the same file under core\SRC.

Just delete the file under templates and it all goes away until you deal with the IOC file again and generate code.

This is a problem ST has to fix.

Oh, and if you have working external memory, I know how to relocate the FreeRTOS heap into that.

and the ongoing saga is located here:

CubeMXIDE multiple definition bug still here

STM32CubeIDE ver 1.8 and, yes, the 8 errors are due to duplicate system_stm32g4xx.c files, removing the generated template file copy allows a "clean" build. Thank you @Harvey White​ for sharing your experience. So as a note to self: when regenerating the code (each time I add an RTOS component or find a better way to configure the project) - delete the duplicate file.

The CubeMXIDE is a neat tool but it does have so much to understand. Experience grows as I journey on this "maze of twisty little passages all different".

Experience is what you get when your were expecting something else! (similar to quote by Randy Pausch)