STM32MP1 support available in SW4STM32

   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 download a short video showcasing this on the ac6-tools website (registration required).

System Workbench for STM32

Unexpected type errors on repeated builds


I’m trying to combine HAL and SPL in my project. I understand this might not be the best idea, but I just wanted to merge something generated from CubeMX (thus HAL based) with the Standard Peripheral Library, which I do prefer to do most of the stuff.

When I have realized that HAL and SPL code might use the same names for types (such as GPIO_InitTypeDef), I made my best to only include headers I really need and I have also renamed the SPL types for names that were still in conflict (->SPL_GPIO_InitTypeDef). This did not seem to work, but after restarting the Ac6 IDE, the build succeeded as I would expect. But when I tried to rebuild again, without any code change, then I got again the same list of errors, complaining that members of GPIO_InitTypeDef couldn’t be resolved. Another restart of IDE and another successful first build followed by errorneous build attempts...

Could anybody please advise how to get rid of this issue? Is there any kind of option to be enabled/disabled in the IDE that could help me? (Such as disabling some kind of indexing or another reason why Ac6/Eclipse suddenly sees conflicting type definitions?).

Also, as a side question: why does STM use the same names for types/macros/etc. in both HAL and SPL? This kind of issues could be easily avoided by prefixing the names with HAL_/SPL_...

Thank you in advance for your help

Okay, after getting back to the issue, I have realized that I have added include paths in the “C/C++ general -> Preprocessor Include paths” leading to the modified SPL headers into the Assembly language section, not to GNU C. After fixing it, I can build my project normally, sorry for the post.
I can’t find a delete button for the post though. If it can’t be deleted, please lock it...