October 8, 2026

First experiences with STM32 CubeMX - getting stared

I have been working with STM32 microcontrollers for years and I have never done anything with CubeMX. My approach has always been to get the reference manual, and figure out how to start writing code. This is true "bare metal" programming.

But just for a change, I thought I would give CubeMX a try to see what it is all about. My conclusion after the afternoon below is that CubeMX is interesting, but not CubeIDE. See the next page on using CubeMX to generate a Makefile, which is definitely how I want to do things.

I tripped over this video by Nick Slayter where he shows you how to get started with a F446 Nucleo board.

To get started, you need a Nucleo board and a USB cable.

Installing the software

I'll bet I have done this before, but I am going to do it again so I know what I am working with, and I'll probably pick up a more recent version. The menu offers downloads for Windows, MacOS (apple silicon), Linux (RPM or generic). Just for the heck of it, I get the latest (2.2.0) for apple silicon. They ask me to login (though I could download as guest). Then they tell me my password expired (I last used it in 2020 or so). I reset the password, then I can login and the download commences.

This yields a xxx.dmg.zip file. The Mac is nice about this. I double click on this and it does some kind of unzip on the fly. I can select the dmg from what it displays and do the install without running unzip myself. The dmg then shows the the usual graphic that asks me to drag the "thing" to my Applications directory. After this I can open up "Applications" and down near the bottom, under "S" I find STM32CubeIDE.

I open it and it wants to set up /Users/tom/STM32cubeide/workspace_2.2.0 as a workspace. It shows me RN0114 (a 36 page release note) in a browser. A bunch of marketing parades by telling me about Eclipse and VScode things I can do. They call this the "information center" and I get rid of it.

STM32CubeMX is a second piece of software that is handled independently. This is somewhat surprising (to me anyway). As it turns out, this is a wonderful thing. I am unlikely to have any use for CubeIDE and will use Makefiles instead. On the other hand, CubeMX looks interesting and useful and can nicely be used without CubeIDE.
They call CubeMX an "initialization code generator".

The same process ensues. I have to login and agree to various things. This gives me a tar.gz file, which is surprising -- it had me wondering if I had made a mistake and downloaded the linux version, but it does say Mac-aarch64, so it is the correct file. I can double click this (but I must double click on the square icon like thing, not the filename). Then it unzips and untars on the fly and shows me the Setup thing. I find the right part to double click on again and it fires up the installer. It installs to /Applications/STMicroelectronics/STM32CubeMX

I don't see it in my Applications "selector", so I use Finder. I go to Applications -- STMicroelectronics (which is a folder). Inside this folder I find STM32CubeMX and can launch it.

A project with CubeMX

I have a STM32H747 Nucleo board handy with a USB cable, so lets see what we can do with it. We start with CubeMX, move on to CubeIDE, then try (without success) to use STlink.

CubeMX offers me a "board selector" under new project. I rattle around with this to find the H747 Nucleo, and now it is offering me two selections and I have no clue which to use. Mine is a ZI2, and after more rattling around I see it, double click, and a bunch of stuff happens with a progress bar to reassure me.

Now a dialog opens. I click "generate demo code" and it shows me that it will exercise the 3 LED, user buttons, and give me a virtual COM port. I say "OK" and now I get a cute image of the chip. It tells me that 102 of 108 GPIO are available!

Pins shown in red are connected to things like the user button or LEDs.
Pins shown in yellow are things like crystals or SWD ports.
Pins shown in pale tan are power and ground.
Pins shown in grey seem to be "available".

You can zoom and pan this screen to more easily read the fine print. You can click on a pin (unless it is locked to some function) and get a menu of functions to assign to it.

The left side has a variety of interesting tools.

Up top are various tabs (including clock setup). The default it comes up with is pinout and configuration.

Finally up at project manager, we give it a name (First) and location (/Users/tom/STM32Cube). Under "toolchain" I select STM32CubeIDE -- but I could have selected "Makefile". I click "generate code" at the upper right. Now it wants to download firmware, so I tell it to do so. This is h7 firmware and it 584M in size, so it takes a while. stm32cube_fw_h7_v1130.zip. Finally it tells me the code has been successfully generated and I select "Open Project".

The project manager shows STM32Cube_FW_H7 V1.13.0 near the bottom. I am pleased that this is handled by CubeMX.

Now, on to STM32CubeIDE

A quick note. CubeIDE is based on Eclipse, namely Eclipse/CDT. It is possible to use VScode instead, configured to work with Cube. ST provides a VScode extension that works with CMake projects.

This does not open automatically when I select "Open Project" like it did for the guy in the tutorial video. I find it in the Applications folder and open it from there after closing CubeMX. It tells me there are no projects in my workspace (namely /Users/tom/STM32cubeide/workspace_2.2.0). Probably if I had given this to CubeMX as my project location this would have worked as expected. I tell it to import from /Users/tom/STM32Cube/First.

Now I see "First" in the navigator on the left. I can expand my way to Core/Src/main.c and look at it in the main window. The generated code watches for a button push and toggles all 3 LED when it sees one.

Build and download the project

To build the project, use the "hammer" icon at top left. Then to run the project, go to the top center and find a big green circle with a right pointing arrow. This brings up a dialog. It tells me it has First.elf, but when I click "OK" it wants me to get (download) an ST-Link server. Who knows why it can't just use the USB like openocd does. I suppose their server does what openocd does. They provide a single option -- a multiplatform zip file. I install it, and now get the error: 
No ST-Link detected
I search and learn that this error is "common" and related to CubeIDE not having /usr/local/bin in the PATH -- this is indeed where st-link is located. The recommended workaround is to launch CubeIDE from the command line via: 
/Applications/STM32CubeIDE.app/Contents/MacOS/STM32CubeIDE
More poking around reveals that st-link is the WRONG cpu type (x86), not ARM apple silicon. I delete it and try: 
brew install stlink
This of course is not at all what we are looking for. At this point, ST needs to get busy and provide their ST-link server ready to install and run on Apple silicon.

Plan B

I see First.elf in /Users/Tom/STM32Cube/First/Debug/First.elf. I should be able to use good old openocd to download and run this.

So, I try it: 

cd ~/STM32Cube/First/Debug
openocd -f interface/stlink.cfg -f target/stm32h7x.cfg -c "program First.elf verify reset exit"
And it works just fine. The code runs. When I press the user button either all 3 LED go on, or they go off.

I see a makefile!

In the directory ~/STM32Cube/First/Debug I see a makefile. I can't resist playing with it. I first do: 
make clean
make
Strangely, typing just "make" does the same as "make clean". When I try "make First.elf" I get: 
arm-none-eabi-gcc "../Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c" -mcpu=cortex-m7 -std=gnu11 -g3 -DDEBUG -DUSE_PWR_LDO_SUPPLY -DUSE_HAL_DRIVER -DSTM32H743xx -c -I../Core/Inc -I../Drivers/STM32H7xx_HAL_Driver/Inc -I../Drivers/STM32H7xx_HAL_Driver/Inc/Legacy -I../Drivers/BSP/STM32H7xx_Nucleo -I../Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.d" -MT"Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.o" --specs=nano.specs -mfpu=fpv5-d16 -mfloat-abi=hard -mthumb -o "Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.o"

arm-none-eabi-gcc: fatal error: cannot read spec file 'nano.specs': No such file or directory
The file "nano.specs" was not in the Debug directory prior to my running "make clean" and locate does not find it anywhere on disk, so this is perplexing. Apparently the --specs option is a way to redefine the rules that gcc uses to run the various things it runs.

I waste some time here, but using this makefile is apparently hopeless.

Conclusion

Now that I know that CubeIDE is Eclipse (a wolf in sheeps clothing), I am inclined to avoid it. I used ADT for android, which was also Eclipse based. It was slow, funky, and except that it was the only game in town, I would not have used it.

VScode is another option, but I don't really want to go in that direction either. It is probably a better choice that CubeIDE.

What I should investigate is CubeMX with the option to generate a makefile project. That could be useful.

Have any comments? Questions? Drop me a line!

Tom's software pages / tom@mmto.org