STM32H563 External-Code Caching: Route Fetches Through the ICACHE Alias

Enabling the STM32H563 instruction cache does not make every external-memory instruction fetch pass through it. The fetch address determines the bus route. To use ICACHE for external code, configure a supported code-region alias and make the executing image use that alias deliberately.

This review pins RM0481 Rev 5, sections 8.4.5–8.4.7. AN5872 Rev 5, section 2.3.1 supplies a related H56x/57x mapping example, demonstrated in an H573 application. No H563 execution, cache-counter experiment or speedup is claimed here.

Follow the instruction address into the cache

RM0481 places ICACHE on the Cortex-M33 C-AHB path for the code region 0x00000000 through 0x1FFFFFFF. Its remapping feature gives supported external physical regions aliases within specified parts of that code region. Access through the alias supplies the route that ICACHE can manage.

For an illustrative 8-Mbyte external-memory region, use the application note’s physical base 0x90000000 and code-alias base 0x10000000. A fetch at alias 0x10001234 maps to physical 0x90001234. The offset stays the same; the physical memory has not moved and no image copy follows merely from enabling the mapping.

A function still executing at its physical external address has not automatically changed routes because ICACHE was enabled elsewhere. Inspect the linked execution address and the actual program-counter location in a controlled diagnostic. A successful debugger read of the stored bytes establishes a different fact from the CPU’s fetch path.

Align the region as a region, not just its first instruction

The H563 implementation supports up to four remapped regions. Region sizes are powers of two from 2 Mbytes through 128 Mbytes. Matching and address construction use the size-dependent upper bits, so both alias and physical bases must respect that region alignment.

For the 8-Mbyte example, the full alias interval is 0x10000000 through 0x107FFFFF, mapped to 0x90000000 through 0x907FFFFF. The upper endpoint is included. A symbol within the first few kilobytes does not establish that the complete linked code and its required literals remain inside the configured interval.

RM0481 warns that extra low bits in the programmed base/remap fields are ignored according to region size. Do not expect a finely offset input value to create an arbitrarily aligned 8-Mbyte window. Decode the register fields into the effective intervals and compare those intervals with the linker map.

Keep the exact H563 address ranges and memory-interface support in that review. Similar register names on another H5 device do not prove identical implementation limits.

Establish memory access before configuring the execution route

A proposed startup design prepares the external memory interface and verifies the intended immutable image before entering it. Run the remap setup from a region whose availability does not depend on the mapping being edited.

Program ICACHE_CRRx only while ICACHE is disabled, as the manual requires. Set each intended region’s base, size, destination and region-enable state deliberately. Also review MPU cacheability and consistent security attribution for the physical and aliased regions; a valid remap is not permission to execute from an otherwise unsuitable region.

The transaction’s cacheability attribute is a separate input to ICACHE. An alias can route correctly yet still carry noncacheable traffic. Preserve that distinction when a performance experiment shows no apparent improvement.

When enabling caching, follow the documented invalidate/busy completion checks. The manual identifies invalidation after reset, explicit invalidation and clearing enable; accesses during an unfinished invalidation can be treated as noncacheable. Merely setting the enable bit does not close that startup sequence.

Keep aliasing distinct from cache enable

An enabled remap region continues translating addresses when ICACHE caching is disabled and for noncacheable traffic. Clearing the cache enable bit therefore does not remove the alias. A diagnostic that expects the alias to stop working after that change is testing the wrong condition.

This permits a useful proposed comparison: hold the alias, immutable code and relevant attributes constant, then compare the supported cache-disabled and cache-enabled cases after their required transitions. It isolates caching more cleanly than simultaneously changing the execution address and memory configuration.

If comparing a physical-address image with an alias-address image, link and validate each placement appropriately. Do not call the same arbitrary binary at a different address by casting a function pointer and assume its absolute references remain valid.

Record route evidence before reporting performance

Retain the external-memory initialization, image hash, linked execution interval, decoded remap interval, MPU attributes and observed instruction address. Then use a declared workload and supported measurements to evaluate any cache benefit, accounting for cold and repeated execution separately.

This article keeps the code immutable and does not provide a live-update or DMA-coherence procedure. Its result is an address-path contract: the intended instructions enter through the code alias, map to the correct stored bytes and carry the intended cacheability. A speed claim requires additional measured evidence.