2019-11-05 05:03 AM
I used cubeMX to generate code for the USB init. Somehow some #include calls are not working. They can't find the file. But if I ctrl+click I get directed to the correct file. I tried refreshing, rebuilding the index, open as admin and specificly adding the files as an include option in the preferences. Nothing worked. Then all of a sudden all hal-driver files produced errors. At some point it resolved itself(?) and then "core_cm7.h" gave me an error message because of a #error. And now I get this message:
file format not recognized. What is happening?
I work on CubeIDE 1.1.0 and STM32h743.
2019-11-05 06:49 AM
When posting build errors, better include ALL output.
There is not much visible from the small screenshot you posted.
I hope you don't try to include object files (*.o) within C code.
2019-11-05 07:52 AM
The error isn't complaining about an #include file.
Don't screen-shot errors when you can cut-n-paste, or access the log output directly. Edit/redact as required.
Look at the object files enumerated in the objects.list file, and perhaps go and inspect the Core/Src/adc.o file and confirm it is a valid file, is of non-zero size, and has an ELF header. Use a File Manager to inspect the file, or dump it to the console.
2019-11-05 08:19 AM
the objects.list seems like the root of the cause. Can I force Cube to remake that file or do I have to edit it manually?
2019-11-05 08:28 AM
Not using CubeMX or CubeIDE here.
adc.o is not an unreasonable name for an object for the linker to be pulling, why the object is missing/broken is another issue. Not sure if the makefile or the tool generates the object list, or if that is a one time thing, or dynamic. These things might become more apparent with some digging..
2019-11-05 09:12 AM
ok. I managed to solve my problem by opening the .project file with notepad++ and manually including the files that he couldn't find.
Edit: I should mention that I transferred the code into a new project. I think the old one is bricked.