The asker is porting HarfBuzz 8.3.0 + FreeType 2.13.2 + LVGL to an NXP i.MX RT1064 Cortex-M7 in a bare-metal configuration (no MMU-backed OS). Latin and simple scripts shape fine, but as soon as they feed an Indic script through HarfBuzz, the MCU hits a hard fault. Their suspicion is recursive GSUB lookups blowing the stack or dereferencing into invalid memory.

This is a deeply interesting embedded problem because it sits at the intersection of three painful constraints:

• HarfBuzz's heap behavior. Indic shaping (e.g. Devanagari) is one of the heaviest GSUB consumers in the spec — reorders, conjuncts, half forms, matra positioning. Internally HarfBuzz builds large temporary buffers and uses recursive lookup contexts. The default hb_buffer_t can grow well past what a typical embedded heap (often 32–128 KB) is sized for.
• Stack depth. GSUB chained context and recursive lookups walk lookup tables via real recursion in HarfBuzz's C++. On Cortex-M with a typical 8–16 KB main stack, a complex Indic cluster can exceed that — and on bare-metal the fault handler often reports an imprecise BusFault rather than a clean stack overflow.
• No MMU / no guard page. A stack overflow silently corrupts whatever sits adjacent in SRAM. The "hard fault during shaping" symptom is often the second-order crash from corrupted heap metadata, not the original overrun.

Direction toward a solution:

• Enable the MPU and place a guard region immediately below the stack. The fault will then fire on the actual overflow, not later. The i.MX RT1064 has 16 MPU regions — one is cheap.
• Inspect SCB->CFSR, HFSR, MMFAR, BFAR in the HardFault handler. STKOF (stack overflow) bit in CFSR is the smoking gun on M7.
• Override HarfBuzz's allocator with hb_malloc_impl / replace via HB_CUSTOM_MALLOC and route to a dedicated, instrumented pool. Track high-water mark.
• Bump the main stack to at least 32 KB before retrying Indic text. The OCRAM on RT1064 has room.
• Build HarfBuzz with HB_TINY / disable unused shapers, but keep HB_NO_BORING_EXPANSION off — Indic specifically needs the universal shaping engine.
• Verify the font is actually loaded into addressable memory. If FreeType is reading glyph data via a stream callback that reaches into XIP flash with bad alignment or past the mapped region, GSUB table walks will fault on the first Coverage table dereference.

Gotchas: FreeType's FT_Stream with custom I/O is a common silent failure — returning fewer bytes than requested makes HarfBuzz read garbage offsets. Also, HarfBuzz uses setjmp-free recursion; there's no graceful "out of stack" path, so detection must happen externally via MPU.