STM32H750 External-Code Delivery: Separate Boot, Storage and Execution Addresses
An STM32H750 product using external application code needs a delivery package for the whole boot path. Programming the large application image is insufficient if the internal boot stage, external-memory setup or execution address does not match it.
The H750 contains 128 KB of internal flash according to DS12556 Rev 8. AN5188 Rev 4 demonstrates an internal-flash boot application that prepares external memory and transfers control. Its examples explain an architecture; they are not a production-ready programmer for every H750 board.
Choose the execution model before choosing file addresses
In the note's execute-in-place model, the CPU executes application instructions directly from memory-mapped external nonvolatile memory. The application is linked for that execution address, and the boot stage must establish access before transferring control.
The model named BootROM in AN5188 means copying stored application bytes into an execution RAM region and then running them there. It does not mean that the MCU's factory system-memory bootloader automatically performs this project-specific copy.
That distinction creates two address roles. The storage location tells the programmer or boot stage where the bytes are kept. The execution location tells the linker where those instructions and data references will live when running. In a copy-to-RAM design, those addresses can differ legitimately.
Write both roles in the build manifest. A binary file does not, by itself, communicate every load or execution assumption. An ELF linked for RAM should not be handed to a flash loader under the assumption that its linked addresses identify the intended nonvolatile storage destination.
Make startup dependencies part of the handoff
AN5188 assigns the boot application responsibility for preparing required memories and setting up the main stack pointer before entering the application. The application must have the resources needed for its own startup available at that point.
Inspect the final linker map and startup code together. If initial stack, initialized data or runtime setup touches an external RAM region, that region cannot remain uninitialized until a later application task. A successful jump to the reset entry does not prove that subsequent startup accesses are valid.
Also establish the vector-table and interrupt arrangement using the actual startup implementation and the H750 reference manual. Treat those as reviewed handoff requirements, not assumptions inherited from an internal-flash example.
Keep resources needed by external code available after the transfer. AN5188 warns against resetting, disabling clocks or changing configuration in ways that make the external storage unavailable. An application-wide peripheral reset routine can therefore conflict with execute-in-place operation even when it was harmless in an earlier internal-flash build.
Match the loader to the real memory hardware
A programming loader must know the external device, its bus wiring and the configuration used to access it. The note's reference boards and loaders cover specified memory arrangements. Their existence does not establish compatibility with another flash part or a reduced-pin custom board.
One particularly easy misreading is the note's restriction on single-QSPI use with its supplied twin-QSPI external loaders. That is a limitation of those example loader arrangements, not a statement that the H750 universally cannot use a single Quad-SPI memory.
Validate the actual programmer-to-memory path separately from the boot-to-memory path. They can use different code while targeting the same storage. Both must agree on device geometry, offsets and the bytes that constitute the application image.
Deliver a paired image set and an address receipt
The production package should identify the internal boot image and its destination, the application image and its storage destination, the application execution address, and the compatible external-memory configuration. Include the expected image sizes and hashes as verification fields, not as a substitute for boot testing.
Record whether the application is executed in place or copied, and which component performs any copy. Preserve the loader identity and board revision with the package. A programming log that says success without identifying those choices is weak evidence for reproducibility.
A proposed acceptance sequence starts from a documented, recoverable board state, programs the intended pair, verifies the stored bytes and then performs a genuine cold startup. It should exercise startup paths that require the external resources, rather than merely stopping at an early debugger breakpoint.
No H750 build, flash operation or boot test was performed here. The deliverable is the address and handoff contract that makes those later tests meaningful. External execution is credible when the stored image, linked image and startup environment describe the same application, not merely when a large file fits in the external flash.
