128 KB of internal flash cannot hold the application. That is the design intent of the STM32H730IBK6Q, a 550 MHz Cortex-M7 value-line device in a UFBGA176+25 body, and it changes the entire shape of a job to copy secured STM32H730IBK6Q software. Most of the code is expected to live in external Octo-SPI memory and execute in place, leaving the small on-chip array for a bootloader, a root of trust and the configuration of the external interface.
The Q Is Not A Packaging Detail
ST training material draws a hard line: on the H730 value line the internal SMPS is available only on the -Q CPN. A board built for the IBK6Q therefore has an inductor, VCAP decoupling and a feedback network that a non-Q board would not need. The die, the 564 KB of SRAM and the 128 KB flash are otherwise the same. Calling this a different chip is wrong; calling it a different power configuration is accurate, and it determines how cleanly the core rail behaves during a read.
Two Storage Domains, Two Threat Models
| Location | Size | Content | Protection |
|---|---|---|---|
| Internal flash | 128 KB | Bootloader, root of trust, Octo-SPI setup | RDP, PCROP, WRP |
| External Octo-SPI | Board-dependent | Application code, assets | OTFDEC AES-128-CTR |
| On-chip SRAM | 564 KB | Runtime buffers | Closed to JTAG at RDP1 |
The H730 is on the AN5281 applicable-products list, which means it carries a crypto/hash accelerator and an on-the-fly decryption engine. OTFDEC decrypts AXI or AHB reads addressed to a memory-mapped Octo-SPI region using AES-128 in counter mode, with the key held inside the MCU. Desoldering the external serial flash and reading it in a programmer therefore produces ciphertext. The key is not in that chip, and at RDP level 2 neither the debug port nor the system bootloader is available to retrieve it.
Security Services Live In System Memory
STM32H7 is unusual in keeping the root security services code for SFI, SBSFU and secure module install in system memory that user code cannot address. Here it remains for the life of the device, which is why a firmware image recovered from the external flash may contain no installer code at all even though secure install was used on the production line.
RDP itself uses 0xAA for level 0, 0xCC for level 2 and any other value for level 1. Level 1 blocks flash, backup SRAM and backup registers from the debugger, and on H7 also blocks RAM access after a system reset. Level 2 is permanent. PCROP adds an execute-only region configured through FLASH_PRAR_PRG, aligned to 256 bytes, and on STM32H7 it survives a level 1 to level 0 mass-erase regression.
Getting At A 176+25 Ball Grid
The IBK6Q is a UFBGA176+25, 10 x 10 mm at 0.65 mm pitch. That is slightly friendlier than the 0.5 mm 169-ball package, but the debug signals are still under the die. A production board usually breaks SWD out to a test pad or a tagged connector; a prototype may not. Locate PA13, PA14 and NRST from the reference design before attaching anything, and check that the external Octo-SPI lines are not multiplexed onto the same bank you need for a probe. Recording the BGA orientation and the board revision alongside the readout makes a second unit much faster to process.
Secure Updates Change What Is Recoverable
Secure boot and secure firmware update mean the external application image is signed, and the verification key stays inside the MCU. An over-the-air update can therefore replace the contents of the serial flash without ever exposing a plaintext binary on the programming interface. A recovered image is a snapshot of one firmware revision, not a reconstruction of every release the product ever shipped. When a customer asks for source-level equivalence, state clearly that the deliverable is the binary present on that specific board, with its version marker and signature block intact.
Scoping A Real Job
Which Octo-SPI device is fitted, is the -Q supply network present, and does the customer need the internal bootloader, the external image, or both? A complete delivery records the 128 KB internal dump, the option byte state, the OTFDEC region configuration, and the raw external contents with a note that they are encrypted. Our bypass methodology page covers how these layers are separated in practice, and the ARM7 STM32F107 cloning case shows a board where external memory decided the whole approach.
For the same die in a 169-ball package, see STM32H730ABI6Q flash access. Where the debug port is already closed, the contact route for device-level work is the remaining option, and the AT32F405 sLib analysis is a useful comparison for another vendor’s execute-only region.