STM32CubeMX Referenced Libraries Can Break an Otherwise Complete Handover

A project archive can contain every visible application file and still depend on a firmware repository outside the archive. If STM32CubeMX generated library references instead of project-local copies, the recipient needs those referenced files too. Diagnose that dependency boundary before replacing missing headers with whichever driver package happens to be installed.

This workflow uses UM1718 Rev 51, May 2026, for CubeMX generation choices and UM2609 Rev 18, June 2026, for the Eclipse project model. It proposes a handover review; no project import or firmware build was executed for this article.

Determine what the generator actually delivered

UM1718 section 4.11.2 distinguishes copying used libraries, copying only necessary library files, and referencing required libraries in the CubeMX repository. With references, the project folder does not contain those library copies. Separately, UM2609 section 1.6 explains that a project’s files can reside elsewhere and be linked into it.

Inspect the saved generation choice and the delivered project metadata together. The current setting in a developer’s installation is insufficient if the last generation used another choice. Look at the actual source and include paths recorded for the configuration being handed over.

Separate a missing file from a wrong file. A missing repository often causes an immediate error. A different repository at the expected path can be more deceptive because compilation may proceed against an unintended implementation. Both cases need the package identity, not merely a directory with a familiar name.

Write a dependency boundary the receiver can follow

For each external source tree, record its purpose, exact release or revision, required local changes, and the path relationship expected by the build. Include HAL, CMSIS, middleware, and any separately maintained components that the particular project actually uses. Do not infer that every component is covered by one folder’s version label.

Classify each path as project-local, repository-relative, or dependent on a machine-specific location or variable. A path can be relative and still leave the delivered tree through ... Conversely, an absolute path may be an intentional, documented installation requirement. The review is about whether the receiver can reproduce the relationship, not a blanket rule that one path spelling is always wrong.

Use compiler output and dependency evidence to establish what is consumed. For a representative application source and driver source, identify the resolved configuration headers and driver files. Preserve these observations with the build configuration. Searching the archive alone cannot reveal which external copy the compiler selected on the author’s machine.

Original dependency-boundary diagram. No particular firmware package is assumed.

Choose copying or referencing deliberately

A self-contained project can be convenient for a one-off supplier handover. If choosing that arrangement, perform the change through the project’s generation and source-control workflow, review the resulting files, and check the intended license and attribution material. Do not simply copy a missing driver into an arbitrary include directory until the error disappears.

A shared referenced repository can also be appropriate when several projects deliberately use the same maintained package. In that case, deliver installation or checkout instructions with a precise identity and an explicit policy for product patches. The recipient should not need access to the author’s home directory, private cache, or undocumented package modifications.

Keep the compiler’s requirement separate from the generator’s requirement. A retained generated tree may have enough source to compile, while future regeneration requires the original Cube package and other generator inputs. State whether the handover promises build reproduction only or continued configuration editing as well. Neither promise should be implied by a successful import dialog.

Test relocation without borrowing the author’s cache

Extract or check out the handover in a separate location and import it into a fresh workspace. Do not destroy the working project to create this test. Supply only the dependencies listed in the handover instructions, then record any additional file, variable, or installation discovered during the attempt.

For an offline-readiness claim, stage the approved dependencies first and perform a controlled check without relying on new downloads. That is a separate test from building while a developer’s complete repository is available. Record a missing dependency honestly rather than silently acquiring a newer version during the test.

After the build, compare the resolved driver and configuration-header paths against the agreed inventory. A receiver may have several Cube packages installed; a successful build is useful only when it consumed the intended one. If changing the library-copy policy requires regeneration, review that generated diff separately from any functional firmware changes.

Accept the delivered dependency set

The acceptance record should identify the application revision, external package identities, product modifications, path setup, and selected build configuration. Attach the resulting log and artifact identity only after the receiver has actually produced them.

This closes a concrete gap: the project archive and the compiler’s input set become explainably connected. A complete handover is not defined by how many folders were zipped. It is defined by whether another engineer can obtain and use the exact dependencies the delivered project expects, without accidentally substituting a different firmware library.