October 9, 2026

First experiences with STM32 CubeMX -- CubeMX and a Makefile

The previous page explored installing CubeMX and CubeIDE. I now want to explore using CubeMX, telling it to generate a Makfile rather than working with CubeIDE.

I launch CubeMX and start a new project. The board selector is hardly convenient, but what seems to work is to start typing "nucleo..." into the "Commercial part number" entry. After a while I get a restricted list of nucleo boards and can scroll down to find mine (Nucleo-H743ZI2).

Again, on the next screen that pops up, I select "generate demo code" and click "OK". Next I select the Project Manager tab and name this project "Second". It remembers the path /Users/tom/STM32Cube from the first project.

The important thing is under toolchain/IDE to select "Makefile" rather than EWARM (whatever that is) or STM32CubeIDE. I do so, then click on "generate code" at the extreme upper right.

Now I use the command line and find Makefile right at the top of the project tree (and no Debug directory). I give it a try. 

cd ~/STM32Cube/Second
make
I get the error: 
stdint.h: No such file or directory

Why are the system include files screwed up?

I have been using arm-none-eabi-gcc quite happily for my own embedded projects, so why are we having this trouble with STM32Cube? One reason is that I never depend on system include files and always put the -nostdinc option on my gcc invocations. I try this and it does not help in this case. The build scheme from ST depends on getting stdint.h from the compiler install. This is not entirely unreasonable, but is not what I would do.

Some searching suggests that I should redo how I installed the toolchain. Using "brew" on my Mac, I first installed arm-none-eabi-gcc as well as binutils, but what is recommended is that I should uninstall those and use: 

brew install --cask gcc-arm-embedded
The "cask" thing is a cute name for a package bundle. One would think that since it provides arm-none-eabi-gcc that it would not conflict with a package by that name, but this is clearly not the case. I remove the individual packages and install the cask using brew and now typing "make" works!
I end up with build/Second.elf

Download this to the board and run it

After fighting with bash and obscure quoting issues, I resorted to Python, which at least makes sense and gets the job done. I wrote a short script I call "flash" and placed it into /Users/tom/bin (which I also put on my PATH). Now I can type: 
flash Second.elf
This works nicely and I am running my code!!

The script looks like this: 

#!/usr/bin/env python3

import os
import sys

file = sys.argv[1]

cmd = f"openocd -f interface/stlink.cfg -f target/stm32h7x.cfg -c \"program {file} verify reset exit\""
print ( cmd )
os.system ( cmd )
I've always hated bash for scripting, and this experience is just one more reason to continue to do so.

Project layout

You can use "make clean" and/or "make -j20" as you see fit.

Have any comments? Questions? Drop me a line!

Tom's software pages / tom@mmto.org