STM32CubeIDE struggling to port app to STM32H723 from F103\G431\F446 code base

[Bags]

As my project has morphed I have started from a STM32F103, moved up to a G431, then a F446.

With a few #defines and tweaks I have a shared main app code base with identical project structures for each of the processor types (that makes it easy to switch between MCU boards as when whilst doing code tests).

All theseSTM32CubeIDE projects have Runtime library = Reduced C, and "do not use default libraries" is ticked. All build fine.

All used CubeMX to generate the appropriate sources etc.., all have 99.9% identical CubeIDE project structures.

As a stepping stone to a STM32F723 I am bodging up a port to an STM32H723, but so far have been unsuccessful in getting it to link. It seems to be having a problem related to the c library area.

(.text._getpid_r+0x0): undefined reference to `_getpid'

/home/main/.eclipse/com.st.stm32cube.ide.mcu.rcp.product_2.0.0_1934254364_linux_gtk_x86_64/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.linux64_1.0.0.202510151430/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/bin/ld: (_getpid): Unknown destination type (ARM/Thumb) in /home/main/.eclipse/com.st.stm32cube.ide.mcu.rcp.product_2.0.0_1934254364_linux_gtk_x86_64/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.linux64_1.0.0.202510151430/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard/libc.a(libc_a-signalr.o)

(.text._getpid_r+0x0): dangerous relocation: unsupported relocation

same error is repeated for _close, _lseek, _read, _sbrk .... etc...

Is there something different between the fundamental c libraries of H7 as compared to all the other MCUs I have used?

If as a bodge I allow the linker to use default libraries, It gets linked ok but with lots of warnings in the same area...

/home/main/.eclipse/com.st.stm32cube.ide.mcu.rcp.product_2.0.0_1934254364_linux_gtk_x86_64/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.linux64_1.0.0.202510151430/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/bin/ld: /home/main/.eclipse/com.st.stm32cube.ide.mcu.rcp.product_2.0.0_1934254364_linux_gtk_x86_64/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.linux64_1.0.0.202510151430/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard/libc_nano.a(libc_a-writer.o): in function `_write_r':

(.text._write_r+0x10): warning: _write is not implemented and will always fail

/home/main/.eclipse/com.st.stm32cube.ide.mcu.rcp.product_2.0.0_1934254364_linux_gtk_x86_64/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.linux64_1.0.0.202510151430/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/bin/ld: /home/main/.eclipse/com.st.stm32cube.ide.mcu.rcp.product_2.0.0_1934254364_linux_gtk_x86_64/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.linux64_1.0.0.202510151430/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard/libc_nano.a(libc_a-writer.o): note: the message above does not take linker garbage collection into account

(the warnings repeated as per the previous fault).

I've tried regenerating from scratch with CubeMX several times but with same end result.

So something looks broken somewhere but I'm having a problem nailing it down.

[MM..1]

IDE version ? MX version? H7 is specific dual core , and for your 723 single core maybe require some other setup.

How is your steps to generate project code?

[Bags]

MX 6.16.1, IDE 2.0.0.

I've been down the "changing MCU on a project" hassle before and now end up generating a new MX project and then porting the existing app code over into it. So I start off from well in the old days CureIDE, and then MX it followed by porting source over - process has worked fine until this H7. Evenutal target will be the F723 but I'm waiting for hardware for that to turn up next week.

Just starting off with the STM32H723 MCU so I've not looked into it much apart from the minimum capabilities required for my app, i.e. max possible USB capability, 3 UARTs, and >128k Flash size.

I just looked at the map file and see the complaining functions are included from "..../v7e-m+dp/hard/libc_nano.a", so perhaps its an issue with floating point (which I don't need for my app).

Will do some more experiments and reading up on the MCU today, and looking into the dual core stuff which may be useful for a bit more horse power!

[Bags · Accepted solution]

Well thats 16 hours of my life I won't get back again.... What a mess under the hood.

The only solution I found was to re-do the entire H7 project from scratch... I think somehow it was generating a "specs=nosys.specs" in the makefile which I just couldn't get rid of.

Step 1 - create your STM32 MCU project using STM32CubeIDE.

Step2 - Then create your STM32CubeMX project and generate its the code.

Step3 - Tidy up your projects folder structure as CubeMX and CubeIDE tend to put things in different places and\or duplicate things.

At each step do a build just to verify it builds ok and backup that version of the project before moving to the next step.

Along the way I met a few annoying STM32CubeIDE bugs....

1 - When adding a project reference to a library, it does the Debug configuration version ok, but the Release configuration setting ends up pointing to the libraries Debug build, not its release build.

2 - ${ProjName} in an include path doesn't always work, in my case it worked for 4 of the projects but not the 5th!

3 - If you try to close a workspace project whilst it is doing a background source indexing, sometimes the IDE just locks up totally and you can't even kill it. Doing a laptop hard power off was the only solution.