2022-02-05 07:44 PM
FreeRTOS project:
code generated includes code in Drivers/CMSIS/Device/ST/STM32F4x/Source/templates
File is of definitions, likely stm32F4xx.h
This conflicts with the file included at Drivers/CMSIS/Device/ST/STM32F4x/Include.
This seems to only happen when using FreeRTOS and CMSIS V2 interface.
Did you mean to include something like stm32F4xx.C in the templates location?
The information is redundant, giving me about 8 multiple definitions. Deleting the template file produces working code.
This has been around for a long while.
2022-02-17 08:37 AM
I looked where you told me to look.
CubeMX standalone worked properly and did not put in the extra file.
CubeMX standalone warns of errors "but the code was generated successfully".
Please note that my file structure does not match yours because of backup concerns.
I have many different projects and workspaces I go between, which reference one common set of code.
attached, please find the .ide.log from that metadata file.
I shall try reinstalling CubeIDE
2022-02-17 08:59 AM
Reinstalling CubeMXIDE does not eliminate the problem.
2022-02-25 02:05 AM
I tried reproducing inside CubeIDE without success.
I also had a look at the ioc-file attached.
What else can we try?
Maybe the metadata stored on Harverys machine is "broken" leading to this issue?
You could try to delete the metadata stored by the tool this will force CubeMX/IDE to re-create new metadata. Should not effect your project. But still, make a back-up copy of the two folders below! Then close CubeIDE/CubeMX.
Then delete this folder:
Did not work? Delete this one too:
Does that make CubeMX behave as it should?
2022-02-25 07:34 AM
I'll try backing up and deleting the folders in a while.
It may be important to note:
Generating the project under cubeMXIDE puts the copy of the file under templates. CubeMX, using the same IOC file, deletes the excess file, which can be seen when refreshing the project with F5. I do not remember CubeMX ever doing that particular behavior.
I do not expect to see a problem with CubeMX. The problem is within CubeMXIDE. I suggest looking (in IDE) for the code that builds the project tree, and specifically the system_stm<processor name> xx.c. There has to be a reason why the software is called to insert that file. It has to do with the FreeRTOS inclusion, I suspect. I do not think that the problem is in the IOC file at all, but rather specifically in CubeMXIDE. That bug has been there for a long while.
1) why is a file put under template? (I'm asking the program logic). Why is it needed? It's a duplicate of the files under core.
2) if the logic is being called twice, then what's calling it? Why?
3) is it program logic that has to do with FreeRTOS?
2022-02-26 10:57 PM
Deleting those two files (I simply renamed them), and running code generation produces the same result. I get a duplicate file as before. CubeMXIDE regenerates both files, though, as you expected.
2023-03-13 06:11 PM
WORKAROUND
ST has not been able to duplicate or analyze the problem.
For some reason, it happens.
Go to the following path which contains the unwanted file:
<project name>/Drivers/CMSIS/Device/ST/<processor name>'/Source/Templates
Under that directory, there will be a file: system_stm32L5xx.c
where system_stm32L5xx.c is the processor you're using.
select that file. Alt Enter to get the file properties.
Go to C/C++ build to find the properties
check "EXCLUDE RESOURCE FROM BUILD"
This becomes a persistent setting.
Each time (in my system) the .ioc file is altered, the software puts back that system<processor>.c file. Thus, deleting it has to happen once per change. With this modification, the file is excluded and nine multiple definitions do not happen.
2023-03-13 08:12 PM
This is strange. Template files should be never copied from the shared "repository" to the user's project dir (by Cube or manually). They are supposed to be "cloned" only once, when the project is created. If new cube versions do this, please file a bug.
2023-03-13 09:12 PM
I have filed a bug, many times. They cannot reproduce it even given most of the project. I conclude that it's something odd at my end, but it is quite consistent. I have a copy generated under /core/src which seems to be the actual file, but what's duplicated seems to act like a link. Delete it, and you're fine (but it gets regenerated the next mod to the .ioc file). Then you need to delete it again. Delete what's under /core, and the compile fails spectacularly.
Seems to be related to using CMSIS, either version 1 or 2. I even had it show up when trying (unsuccessfully) to make AZURE behave reasonably.