ASELSTM
commented
10 months ago Hi @thestumbler,
The point you reported is actually related to the CubeMX generation problem and not to the firmware published in this repository. Unfortunately, we don't treat aspect related to CubeMX tool in our GitHub repositories. They are rather treated at the STM32CubeMX dedicated page of the ST Community .
Since this issue is not directly related to the STM32Cube firmware but rather to our ecosystem, please allow me then to close this thread. Thank you for your comprehension.
With regards,
Describe the set-up
Describe the bug This report here is just to point to a similar bug from the STM32CubeF7 repository. I was experiencing the same error reported by that user. According to the thread, the problem was mistakenly not including syscalls.c, and had been recently fixed on the F7 repo. The internal ST reference number is 159701.
I haven't dug deeply into this in my case, but simply copying that file into my CubeMX-generated project's source code directory and updating the Makefile accordingly solved the linker errors. Therefore I think that same F7 issue applies to the H7 CubeMX repository as well.
How To Reproduce In my case, I just made a new blank project using CubeMX for this dev board. The original user did something different and was importing a project.
The modules that you suspect to be the cause of the problem Something about the way the CubeMX code generator identifies which files to copy to the project directory has changed recently.
The use case that generates the problem
How we can reproduce the problem Make a blank CubeMX project, Makefile, and try to build.
Additional context Manually copy the missing file and edit the Makefile