Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


You are viewing a reply to can't find include file  

can't find include file

Creating my project from the scratch with the newest version of all tools didn’t helped. After that I deleted my workspace and stared all over again, with much better results, but still with errors. Through some investigation I found out that in the “stm32f0xx.h” the line with my target device was still commented. After fixing this, the compiler kept complaining about unresolved “SysTick_IRQn”. I found out, that in my case it’s a replacement for -1. After fixing this problem my LED blink program worked.
Next step, I created a new project, which should include i2c. Same problems as above, a lot of unresolved symbols. I added include statement after include statement in my “main.c”. With every include some errors disappeared, but never all. I tried to follow the include chain, which starts with #include “stm32f0xx_hal.h”. I added a symbol, macro or what ever to this header file project//Drivers/STM32F0xx_HAL_Driver/Inc/stm32f0xx_hal.h The compiler complained, that this symbol is not defined. I renamed this header file, no complains about a not existing file. I found 5 files with this name in my workspace. The one that really counts was /nucleo-f091rc_hal_lib/HAL_Driver/Inc/stm32f0xx_hal.h
In the project “properties -> C/C++ Build -> Settings -> MCU GCC or G++ Compiler -> Includes” I found, that the workspace include paths are first in list, before the project paths. In my opinion completely wrong. Include files in the workspace are common to all projects. If you have some project specific modifications in a header file, you place it in one of your project directories. But this doesn’t help, if they are nor taken before the workspace directories.
I also have to say, that all these measures didn’t resolved the include chain problems. I have to make more investigations. And probably it’s not a good idea to have more than one project in one workspace.