January 11, 2024

STM32CubeMX -- using the Makefile option

I put a script called "cube" in /home/tom/bin to start STM32CubeMX.

Under "project manager" in "Project" there is a "Toolchain/IDE" option and I am overjoyed to learn I can specify "Makefile" here.

I select my H747-DISCO board, take all the defaults, then:

Then I make the following selections under code generation: Then I click the "Generate Code" button. The results end up in: 
/home/tom/CubeMX/FirstDefaults

Errors!

I do: 
cd /home/tom/CubeMX/FirstDefaults
cd Makefile
make
I get the error: 
../../CM7/Core/Src/main.c:20:10: fatal error: main.h: No such file or directory
This is because this is garbled "-I../..//u1CM7/Core/Inc". Some how the extra "/u1" has been inserted garbling the path. I fix this, editing the makefiles in CM4 and CM7.
Next I get: 
/usr/lib/gcc/arm-none-eabi/13.1.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
    9 | # include_next
This is from within a standard gcc file. I add the switch "-ffreestanding" to the gcc options and that error goes away. This option is supposed to indicate:
Assert that compilation takes place in a freestanding environment. This implies -fno-builtin. A freestanding environment is one in which the standard library may not exist, and program startup may not necessarily be at main. The most obvious example is an OS kernel.
Now I get: 
../../Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_def.h:32:10: fatal error: math.h: No such file or directory
   32 | #include
This is what is known as "include file hell". Do we really need math.h? I comment the include out in these two files: 
stm32h7xx_hal_def.h:#include 
stm32h7xx_ll_rcc.h:#include
(Indeed this turns out to be a bad idea. We need "float_t" which is defined in math.h; see below.

Now I get this: 

arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -DCORE_CM4 -DUSE_HAL_DRIVER -DSTM32H747xx -I../../CM4/Core/Inc -I../../Drivers/STM32H7xx_HAL_Driver/Inc -I../../Drivers/STM32H7xx_HAL_Driver/Inc/Legacy -I../../Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../../Drivers/CMSIS/Include -Og -ffreestanding -Wall -fdata-sections -ffunction-sections -g -gdwarf-2 -MMD -MP -MF"build/main.d" -Wa,-a,-ad,-alms=build/main.lst ../../CM4/Core/Src/main.c -o build/main.o
In file included from ../../CM4/Core/Src/main.c:21:
../../CM4/Core/Inc/adc.h:30:10: fatal error: string.h: No such file or directory
   30 | #include "string.h"
This has me wondering if adding the -ffreestanding switch is the wrong thing to do. I get the same error about stdint from one of my own Makefiles: 
arm-none-eabi-gcc -mcpu=cortex-m7 -mthumb -g    -c -o main.o main.c
In file included from main.c:5:
/usr/lib/gcc/arm-none-eabi/13.1.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
    9 | # include_next
Based on an online tip, I do this: 
su
dnf install arm-none-eabi-newlib
Indeed, this fixes the problem for my own project makefile. And the CubeMX compile goes along much further until it hits: 
../../Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc.c: In function 'HAL_RCC_GetSysClockFreq':
../../Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc.c:1391:3: error: unknown type name 'float_t'; did you mean 'float'?
 1391 |   float_t fracn1, pllvco;
I go back and uncomment the includes of math.h. That fixes this problem and the build now goes to completion with just a few warnings. It ends as follows: 
arm-none-eabi-size build/FirstDefaults_CM4.elf
   text	   data	    bss	    dec	    hex	filename
  33620	    216	   4640	  38476	   964c	build/FirstDefaults_CM4.elf
arm-none-eabi-objcopy -O ihex build/FirstDefaults_CM4.elf build/FirstDefaults_CM4.hex
arm-none-eabi-objcopy -O binary -S build/FirstDefaults_CM4.elf build/FirstDefaults_CM4.bin

arm-none-eabi-size build/FirstDefaults_CM7.elf
   text	   data	    bss	    dec	    hex	filename
  14180	     24	   1720	  15924	   3e34	build/FirstDefaults_CM7.elf
arm-none-eabi-objcopy -O ihex build/FirstDefaults_CM7.elf build/FirstDefaults_CM7.hex
arm-none-eabi-objcopy -O binary -S build/FirstDefaults_CM7.elf build/FirstDefaults_CM7.bin
make[1]: Leaving directory '/u1/home/tom/CubeMX/FirstDefaults/Makefile/CM7'
Yes, it builds two executables, one for the CM7 core and one for the CM4 core.

Where is that build directory?

CubeMX/FirstDefaults/Makefile/CM7/build
CubeMX/FirstDefaults/Makefile/CM4/build

Conclusion

I did need to hack out the /u1 thing in the include path by hand.
If and when I repeat all this, that should be the only thing I need to do.

Adding -ffreestanding did not hurt or help and it sort of seems like the right thing.

I needed to install this mysterious "newlib" package. The claim is:

Newlib is a C library intended for use on embedded systems. It is a conglomeration of several library parts, all under free software licenses that make them easily usable on embedded products.
This link tells more about it than I find anywhere else.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org