2026-05-12 5:03 AM
Hi all,
We're working on a TouchGFX-based UI project on STM32H7S7L8H6H, with a 32 MB APS256 PSRAM on XSPI1 clocked at 200 MHz. The MCU has a 16 KB D-cache.
As the project has grown, we've been trying to move some internal RAM consumers out to PSRAM. The current candidate is the TouchGFX FrontendHeap (~113 KB) — a C++ object pool, so it's densely accessed by the
CPU (vtable lookups, member dereferences, etc.).
We configured the MPU to give the PSRAM region cacheable attributes. Without caching, the screen visibly glitches while drawing operations touch the heap, so cacheable is what we need.
The problem: as soon as the FrontendHeap region is marked cacheable, we get a hardfault very early in rendering. Inspection shows the C++ vtable pointers in the heap are corrupted (MMFAR consistently lands
inside the heap, e.g. 0x2E0C1B8C).
What we've already tried, all with the same failure signature:
- Write-Back, Write-Allocate (TEX=001, C=1, B=1)
- Write-Through (TEX=000, C=1, B=0)
- With and without explicit cache maintenance (SCB_CleanInvalidateDCache_by_Addr around accesses)
- With and without TouchGFX's cache hooks
- MPU isolation — placing FrontendHeap alone in a cacheable sub-region while the rest of PSRAM stays uncached
Is anyone running a similar config (XSPI PSRAM + cacheable + heavy CPU access) successfully? Or is there any workaround to use cache for accessing FrontEnd heap object from an External RAM?
Any input appreciated.
Truly yours,
Amir