STM32CubeH7: the full firmware package for STM32H7 boards

What the STM32CubeH7 package covers

The package is the full embedded software platform for one microcontroller family, and the README breaks it into five layers. CMSIS core and device modules correspond to the Arm core implemented in the H7 products. The STM32 HAL and LL drivers form an abstraction layer whose stated purpose is maximised portability across the STM32 portfolio. BSP drivers cover each evaluation, demonstration and Nucleo board ST provides for this series. Middleware libraries arrive as a consistent set, named examples being RTOS, USB, FatFS, graphics and a touch sensing library. Finally there is a full set of software projects, basic examples, applications and demonstrations, for each supported board.

The layout mirrors those layers at the top level of the repository: Drivers, Middlewares, Projects, Utilities and Documentation, alongside package.xml, an sbom_cdx.json software bill of materials, Release_Notes.html, and governance files such as CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md and SW_Security_Level.md.

This is aimed at engineers who want the vendor's own stack rather than a bare CMSIS project. The scale is the point: one clone gives you drivers, board support, middleware and worked examples for every board in the range.

Why the repository is a submodule assembly

The README states plainly that the repository was created using the `git submodule` command, and an important callout appears right under the title. That single design decision shapes the whole workflow. Directories such as Drivers, Middlewares and Projects are not stored in this repository; they are references to other repositories pinned at specific commits in the .gitmodules file.

The consequences are practical. A shallow clone of this repository alone gives you almost nothing, because the referenced trees are empty until their submodules are initialised. Version consistency is handled by pinning, so the submodule commits recorded here define one coherent firmware version across drivers, middleware and projects. And the upstream halves can move independently, which is why a plain `git pull` is not sufficient to refresh the tree.

There is a second wrinkle. The README notes that the GitHub version may be ahead of the same firmware available on st.com or through STM32CubeMX, because GitHub runs a rolling release process. So a clone of the master branch is not necessarily the release you would download as a ZIP from the vendor's site.

Cloning and pinning a firmware version

The README gives four concrete steps. The first clones the repository together with its linked submodules, which requires the `--recursive` option.

git clone --recursive https://github.com/STMicroelectronics/STM32CubeH7.git

You should see the submodule directories populated after the clone finishes rather than left empty.

The second step applies to an existing local copy and needs two commands, not one: the pull updates the top level, and the submodule update pushes the new submodule commits into the working tree.

git pull
git submodule update --init --recursive

The third step pins the tree to the same version published on st.com. The `vX.Y.Z` placeholder is replaced with the targeted tag, and this has to run after either of the first two instructions has completed.

git checkout vX.Y.Z # Specify the targeted vX.Y.Z version

The fourth step avoids the round trip entirely by cloning a specific tag directly, with a shallow history.

git clone --recursive  --depth 1 --branch vX.Y.Z https://github.com/STMicroelectronics/STM32CubeH7.git

The README flags that `--depth 1` is optional, useful for skipping earlier commits, and warns that using the GitHub Download ZIP option instead of `git clone` leaves the submodules to be collected and added by hand.

The three middleware libraries missing from GitHub

A note in the README lists middleware that is not in this repository: `./Middlewares/ST/STM32_Audio`, `./Middlewares/ST/STemWin` and `./Middlewares/ST/TouchGFX`. The stated reason is restrictive licence terms that require user approval through a click-through procedure. Projects that depend on them, and the demos, applications and examples that use them, are excluded as well, and the README points to a list of unavailable projects in Projects/README.md.

The remedy is the full firmware package on st.com, downloadable from the STM32CubeH7 product page, with a login or registration required if you have no account. This is the sharpest boundary in the project, because audio, the emWin GUI and the TouchGFX GUI are exactly the features that make H7 boards interesting, and they are the three you cannot get from a plain clone.

Worth checking the specific middlewares your design needs before committing to the repository as your source, since the gap is not obvious from the directory listing alone.

Board coverage and the Projects tree

The README lists 21 boards under the STM32H7 heading. They span the Nucleo range, including the NUCLEO-H7A3ZI-Q, NUCLEO-H723ZG, NUCLEO-H743ZI and its revision 2, NUCLEO-H753ZI and its revision 2, NUCLEO-H745ZI-Q and NUCLEO-H755ZI-Q. Alongside them sit the Discovery and Evaluation and development kits: STM32H7B3I-DK, STM32H7B3I-EVAL, STM32H735G-DK, STM32H743I-EVAL, STM32H743I-EVAL2, STM32H753I-EVAL, STM32H753I-EVAL2, STM32H745I-DISCO, STM32H747I-DISCO, STM32H747I-DISC1, STM32H747I-EVAL, STM32H757I-EVAL and STM32H750B-DK.

The README explains that the projects run directly on STM32H7 series boards, and that each Projects directory named for a board holds its Applications, Demonstration and Examples sets. That is the practical route into the package: pick your board by name, then work down to the example that matches the peripheral you are bringing up.

The projects are also the best available reference for peripheral configuration, since each one is a known-good starting point for a specific board and a specific set of pins. For troubleshooting, the README points to CONTRIBUTING.md rather than to a separate troubleshooting document.

Where STM32CubeH7 is the wrong choice

This package is large and it is opinionated about the vendor's own stack. A team that only needs a handful of HAL calls for one custom board gets those calls through STM32CubeMX, which generates a project with only the peripherals selected, and does not need a multi-repository clone at all. Pulling the full package means the whole Drivers and Middlewares tree lands on disk even if you touch one UART.

There is a licensing asymmetry to keep in mind too. GitHub lists the repository licence as one it cannot classify, with a LICENSE.md file at the root, while three middleware components inside the package carry their own restrictive terms. The parts you cannot clone are exactly the parts whose terms differ from the rest, so a project that depends on TouchGFX cannot treat the whole tree as one uniform set of terms.

For a product built around audio or the emWin or TouchGFX interfaces, that is not a reason to avoid the package, but it is a reason to plan the download from st.com on day one rather than discovering the gap later.

Version tracking, security files and maintenance cost

The package carries a version badge in the README at v1.13.0 and a Release_Notes.html at the repository root, linked from the README as the place where the content of the release is described. The repository itself publishes no GitHub releases, so the git tags are the version history to track, and the rolling release process means master can be ahead of the st.com package. If you need the exact vendor release, pin a tag with `git checkout vX.Y.Z` rather than following master.

The repository also includes an sbom_cdx.json software bill of materials in CycloneDX format, a SECURITY.md file describing how to report security issues, a SW_Security_Level.md file, and a .github directory. For a package with this many third-party components, having the bill of materials in the tree is a genuine convenience for compliance work.

The repository is not archived and its last push was on 2026-09-04, so the tree is still being worked on. The upgrade cost is not a package manager step but a submodule discipline: pull, then update submodules, then retest, and remember that a plain pull without the submodule update leaves you on stale drivers.

Editorial conclusion

Take STM32CubeH7 if you are targeting an STM32H7 Nucleo, Discovery or Evaluation board and want the vendor's driver stack, middleware and ready-made projects in one place; stay with STM32CubeMX plus a CMSIS toolchain if you need only a bare-metal project or a specific vendor. Before starting, check which of STM32_Audio, STemWin and TouchGFX your project needs, since the GitHub copy omits them and they must be fetched from the st.com download with a login.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. STMicroelectronics/STM32CubeH7 on GitHub