Skip to main content
SoonuVermaMKU
Visitor
September 26, 2026
Question

STM32N657 (Cortex-M55) crashes / loses debug connection when jumping from FSBL to XIP Appli in external NOR — vector table confirmed correct

  • September 26, 2026
  • 0 replies
  • 3 views

Setup:

  • MCU: STM32N657X0HXQ (Cortex-M55), STM32N6570-DK
  • Boot architecture: FSBL (runs from internal RAM) → single secure Appli, no TrustZone split, executing XIP from external NOR (XSPI2, mapped at 0x70000000)
  • PSRAM (XSPI1, APS256XXN-OBR-BG) also mapped via the same EXTMEM_Manager framework
  • FW package: STM32Cube FW_N6 V1.4.1
  • Linker script places Appli's .isr_vector at 0x70100400 (0x400-byte header region reserved before it)

What's confirmed working:

  • FSBL boots, maps both PSRAM and NOR successfully via EXTMEM_MemoryMappedMode()
  • NOR flash program/verify succeeds cleanly via ST-LINK GDB server
  • I independently verified the vector table content with a raw GDB memory read (x/4xw 0x70100400), bypassing Eclipse's Memory view (which was misleadingly showing byte-reversed values — a display artifact, not real data): the actual words are correct — 0x34100000 (valid SP, matches linker's RAM origin) and 0x701066a5 (valid Reset_Handler address, correct Thumb bit set, inside the linked ROM range)

The problem:
JumpToApplication() (standard ST stm32_boot_xip.c middleware pattern) does the usual:

SCB->VTOR = (uint32_t)Application_vector;JumpToApp = (pFunction)(*(__IO uint32_t *)(Application_vector + 4u));__set_MSP(*(__IO uint32_t *) Application_vector);__set_PRIMASK(primask_bit);JumpToApp();

 

Despite the vector table content being verified correct via raw GDB memory read, stepping into JumpToApp() causes the debugger to immediately report Target is not responding, retrying... and eventually lose the ST-LINK connection entirely (GdbSession, Lost target connection, Exiting...).

What I'm trying to isolate:

  • Is there a known gotcha on Cortex-M55/STM32N6 specifically around I-Cache/D-Cache being disabled before the jump but the target application's own cache/MPU config not being (re-)established quickly enough, causing an immediate fault?
  • Any known issue with SCB->VTOR being set to an address in external memory-mapped NOR rather than internal flash/RAM — does VTOR require the vector table to be in a specific memory region, or have alignment/timing requirements that memory-mapped XIP could violate?
  • Since this is a single secure app (no TrustZone S/NS split), is there anything RIF (Resource Isolation Framework) or a secure/non-secure boundary related on STM32N6 that could silently block/fault a jump into this address range even though it's readable via SWD?
  • Could FSBL's own cache/MPU teardown (disabling I-Cache/D-Cache right before the jump) interact badly with a target still expecting those enabled — is there a required MPU/cache re-init step specific to N6 that ST's generic stm32_boot_xip.c middleware doesn't handle?

Any pointers to a working reference example of FSBL→Appli handoff specifically for STM32N6 NOR XIP (as opposed to internal flash or PSRAM-only) would help a lot — happy to share more logs/config if useful.

Terms & ConditionsAccessibility statement