And, if you install System Workbench for Linux in
When the firmware is placed in a library project, it is compiled independently of your application, then linked with your application. This setup informs the linker of what code is really required (your application) and what code should only be included when used by some “required” code. This selection can then be done on a function by function level on the external static library.
On the opposite, if you include the code from the firmware into your application project, then all the code from the firmware will be included in the final object code, as the linked does not know how to choose what is really needed.
Note that if you develop middleware code, you should also deploy it as a static library, so that only the relevant part of your code (at function granularity) is included in your final system.
When creating your project, you probably selected to import the low-level drivers as static library. This error does not really exists and should not affect the usage. This is a known bug, we are working on it not to display the error message.
If you find it inconvenient, you can remove this message. Go to the “Problems” view (Windows > Show views > Problems) then select the errors and delete them. Unlike real problems, these errors won’t appear again. The error could also disappear when System Workbench is restarted.
Basically there is currently three possibilities:
In all cases CubeMX may be used to re-generate code and will keep your modifications if they are placed between the code generation “User Code begin/end” comments.
It is usually advisable to use one of the first two possibilities, as the third one will impair the ability to place the generated code under source-code-management systems like GIT or SVN.
Detailed instructions are provided in the Ac6 System Workbench for STM32 documentation at Importing a STCubeMX generated project