Following a similar procedure described in this question, I tried choosing "Makefile" as my Toolchain/IDE. However, the generated Makefile has a couple of major problems.
Firstly, the C_SOURCES section had every file listed twice (specifically, it had a list of files, concatenated to itself.) This was easy enough to fix, giving the attached file. However, the next problem is far more difficult to deal with -- the result of running 'make' is as follows:
$ make
... <snip> ...
arm-none-eabi-gcc build/main.o build/stm32h7xx_it.o build/stm32h7xx_hal_msp.o build/main.o build/stm32h7xx_it.o build/stm32h7xx_hal_msp.o build/stm32h7xx_hal_cortex.o build/stm32h7xx_hal_tim.o build/stm32h7xx_hal_tim_ex.o build/stm32h7xx_hal_rcc.o build/stm32h7xx_hal_rcc_ex.o build/stm32h7xx_hal_flash.o build/stm32h7xx_hal_flash_ex.o build/stm32h7xx_hal_gpio.o build/stm32h7xx_hal_hsem.o build/stm32h7xx_hal_dma.o build/stm32h7xx_hal_dma_ex.o build/stm32h7xx_hal_mdma.o build/stm32h7xx_hal_pwr.o build/stm32h7xx_hal_pwr_ex.o build/stm32h7xx_hal.o build/stm32h7xx_hal_i2c.o build/stm32h7xx_hal_i2c_ex.o build/stm32h7xx_hal_exti.o build/stm32h7xx_hal_eth.o build/stm32h7xx_hal_eth_ex.o build/stm32h7xx_hal_fdcan.o build/stm32h7xx_ll_fmc.o build/stm32h7xx_hal_sdram.o build/stm32h7xx_hal_ltdc.o build/stm32h7xx_hal_ltdc_ex.o build/stm32h7xx_hal_dsi.o build/stm32h7xx_hal_qspi.o build/stm32h7xx_hal_sai.o build/stm32h7xx_hal_sai_ex.o build/stm32h7xx_ll_sdmmc.o build/stm32h7xx_hal_mmc.o build/stm32h7xx_hal_mmc_ex.o build/stm32h7xx_hal_uart.o build/stm32h7xx_hal_uart_ex.o build/stm32h7xx_hal_pcd.o build/stm32h7xx_hal_pcd_ex.o build/stm32h7xx_ll_usb.o build/system_stm32h7xx_dualcore_boot_cm4_cm7.o build/startup_stm32h745xx_CM7.o build/startup_stm32h745xx_CM4.o -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -specs=nano.specs -Tstm32h745xx_flash_CM4.ld -lc -lm -lnosys -Wl,-Map=build/stm32h7demo_CM4.map,--cref -Wl,--gc-sections -o build/stm32h7demo_CM4.elf
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: build/main.o: in function `main':
/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/../CM4/Src/main.c:122: multiple definition of `main'; build/main.o:/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/../CM4/Src/main.c:122: first defined here
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: build/main.o: in function `Error_Handler':
/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/../CM4/Src/main.c:727: multiple definition of `Error_Handler'; build/main.o:/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/../CM4/Src/main.c:727: first defined here
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: build/main.o:/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/../CM4/Src/main.c:67: multiple definition of `Rx_Buff'; build/main.o:/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/../CM4/Src/main.c:67: first defined here
... <snip> ...
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: build/startup_stm32h745xx_CM4.o:(.isr_vector+0x0): multiple definition of `g_pfnVectors'; build/startup_stm32h745xx_CM7.o:(.isr_vector+0x0): first defined here
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: build/startup_stm32h745xx_CM4.o: in function `WAKEUP_PIN_IRQHandler':
/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/startup_stm32h745xx_CM4.s:111: multiple definition of `Default_Handler'; build/startup_stm32h745xx_CM7.o:/home/rbowmaker/stm32h7demo/firmware/stm32h7demo/startup_stm32h745xx_CM7.s:111: first defined here
... <snip> ...
The first thing of note is that CM4/Src/main.c and CM7/Src/main.c both apparently get compiled to build/main.o, so one will be clobbering the other. And then, with the build/main.o being listed twice, "multiple definition" errors occur for every symbol. Secondly, *_CM7.o files are conflicting with *_CM4.o files.
I am only just dipping my toes into dual-core ARM processor for the first time, so I'm just guessing here, but aren't the CM4 and CM7 builds supposed to be compiled into separate ELF/hex files? Is there any chance STM32CubeMX can be modified to generate valid Makefiles soon?
