STM32N6 platform support - #15214

src/platform/STM32/link/STM32N657XX_LRUN.ld:296

• The .DMA_RW_D2 section is no longer marked NOLOAD. DMA scratch/descriptor regions are typically not loaded from FLASH (and startup code won’t initialize them), so making this a loadable section can create unexpected load/zeroing behavior and larger images. Align this with the other DMA sections by marking it NOLOAD (and only placing it in D2_RAM).
  Makefile:203
• Revision detection now checks for a .git/ directory. In git worktrees/submodules, .git is commonly a file (not a directory), so this can incorrectly leave REVISION as norevision even though git metadata is available. Consider checking for .git (file or dir) or using git rev-parse --is-inside-work-tree to decide whether to compute REVISION.

REVISION := norevision
ifneq ($(wildcard .git/),)
ifeq ($(shell git diff --shortstat),)
REVISION := $(shell git rev-parse --short=9 HEAD)
endif
endif

src/main/fc/init.c (1)

1073-1078: ⚡ Quick win

TODO acknowledged — consider raising this as a tracked issue.

Skipping unusedPinsInit() wholesale on N6 leaves any genuinely unused but writable pin floating, which is a small EMI / current-draw risk on production hardware and a footgun if someone later writes target code that depends on the floor-clean state this function provides on other STM32 families. The right long-term fix is probably for IOTraversePins (or its callees) to consult RIFSC RISC_SECCFGR/PRIVCFGR before poking MODER, but that's clearly outside the scope of this PR.

The #if !defined(STM32N6) guard is fine as a short-term workaround given the PR is already marked draft. Worth tracking explicitly so it doesn't get lost.

Want me to draft a small RIFSC-aware filter that IOTraversePins can call to skip restricted GPIO banks, and/or open a tracking issue for this TODO?

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/main/fc/init.c` around lines 1073 - 1078, The current `#if`
!defined(STM32N6) skips unusedPinsInit() on N6 which risks floating writable
pins; create a tracked issue for implementing a RIFSC-aware filter (so
IOTraversePins/IOConfigGPIO consult RISC_SECCFGR/PRIVCFGR and skip restricted
banks) and add a concise TODO comment in init.c referencing that issue ID and
explaining why the guard is temporary; include the symbols unusedPinsInit,
IOTraversePins, IOConfigGPIO, RISC_SECCFGR, and PRIVCFGR in the comment so
future work knows exactly what's required.

src/platform/STM32/sdio_n6xx.c (2)

747-750: 💤 Low value

Both SDMMCx_IRQHandler dispatch to the same hsd1 — fine today, fragile later.

Functionally correct given the active-controller selection in sdioPinConfigure(), but if anyone ever enables both SDMMC1 and SDMMC2 simultaneously (or stubs in a second handle), this collapses to a single handler and the wrong instance will be polled in IRQ context. Worth a // only one of these is wired up at a time — sdioHardware->instance picks the active controller comment so a future maintainer doesn't paste a second handle here without thinking.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/sdio_n6xx.c` around lines 747 - 750, Both SDMMC1/SDMMC2
IRQ handlers currently call HAL_SD_IRQHandler(&hsd1), which works now but is
fragile if both controllers are enabled; add a brief explanatory comment in
SDMMC2_IRQHandler (and SDMMC1_IRQHandler if present) noting that only one
controller is wired at a time and sdioHardware->instance selects the active
controller in sdioPinConfigure(), so the handler intentionally uses hsd1; if
future work enables both controllers, replace the hardcoded hsd1 usage with
instance-aware dispatching (e.g., choose the correct SD handle based on
sdioHardware->instance) rather than copying the same handle.

---

197-206: ⚡ Quick win

Fix the misleading comment on PRIVCFGR.

The trailing comment // NPRIV = 0 reads as if there is a field called NPRIV that you're setting to 0. The GPIOx_PRIVCFGR field is PRIV — clearing the bit means "non-privileged access allowed". The current text inverts the polarity of what you're actually writing.

📝 Suggested wording

-    port->SECCFGR  |=  mask;     // SEC = 1
-    port->PRIVCFGR &= ~mask;     // NPRIV = 0
+    port->SECCFGR  |=  mask;     // PRIV pin marked secure
+    port->PRIVCFGR &= ~mask;     // PRIV = 0 → non-privileged access allowed

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/sdio_n6xx.c` around lines 197 - 206, In sdioRifMarkPin,
the trailing comment on the PRIVCFGR write is misleading; instead of saying
“NPRIV = 0” update the comment for port->PRIVCFGR &= ~mask to correctly reflect
that clearing the PRIV bit allows non-privileged access (e.g. “PRIV = 0 →
non-privileged access allowed”); keep references to IO_GPIO, IO_Pin, SECCFGR and
PRIVCFGR so the change is localized to the comment in sdioRifMarkPin.

src/platform/STM32/system_stm32n6xx.c (3)

161-167: 💤 Low value

NVIC ICER/ICPR loop count consistency with startup_stm32n657xx.s.

The C loop here correctly uses sizeof(NVIC->ICER) / sizeof(NVIC->ICER[0]), but the corresponding assembly loop in startup_stm32n657xx.s (lines 67 and 74) hardcodes r3 = #16``. Cortex-M55 with up to 480 IRQs needs 15 registers; 16 is fine and harmless (writes to reserved tail are ignored), but the two loops are now visually inconsistent on a "what's the iteration count" question. Either drop the assembly down to a CMSIS-derived constant (via .equ from a generated header) or accept the duplication with a one-line comment in both spots cross-referencing each other.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/system_stm32n6xx.c` around lines 161 - 167, The NVIC
register-clear loops in system_stm32n6xx.c (the for loop using
sizeof(NVIC->ICER) / sizeof(NVIC->ICER[0])) and the hardcoded loop count in
startup_stm32n657xx.s are inconsistent; fix by either (A) making the assembly
use a shared CMSIS-derived constant (add a .equ in the generated header and
reference it in startup_stm32n657xx.s) or (B) add a one-line comment in both
places cross-referencing each other and explaining why the assembly uses 16
iterations (writes to reserved tail are ignored) so the visual discrepancy is
documented; update the comment in system_stm32n6xx.c near the
NVIC->ICER/NVIC->ICPR loop or modify startup_stm32n657xx.s to reference the
shared constant accordingly.

---

308-432: 💤 Low value

Every HAL failure path is an unrecoverable while (1); — at least leave a fingerprint.

There are seven while (1); spins inside SystemClock_Config() (lines 321, 324, 337, 350, 368, 397, 421), each on a distinct HAL call. The PR design is "let the OBL/IWDG path recover" (and the comment in systemResetToBootloader at 452-462 confirms this is intentional), but on a cold boot before IWDG is armed there's nothing differentiating which spin you ended up in.

For bring-up reliability, write a marker into the .bf_obl_dbg debug buffer before each spin so the OBL @DBGRAM DFU alt can tell the host which HAL step failed:

♻️ Sketch (optional)

+#define BF_OBL_FAULT(code)  do { *(volatile uint32_t *)0x24100130UL = (code); __DSB(); } while (0)
     ...
-    if (HAL_PWREx_ConfigSupply(PWR_EXTERNAL_SOURCE_SUPPLY) != HAL_OK) {
-        while (1);
-    }
+    if (HAL_PWREx_ConfigSupply(PWR_EXTERNAL_SOURCE_SUPPLY) != HAL_OK) {
+        BF_OBL_FAULT(0xDEAD0001);
+        while (1);
+    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/system_stm32n6xx.c` around lines 308 - 432,
SystemClock_Config contains seven unrecoverable spins; before each while (1);
write a distinct marker into the .bf_obl_dbg debug buffer so the OBL DFU alt can
identify which HAL call failed. Concretely: in SystemClock_Config, immediately
before the failure branches that follow HAL_PWREx_ConfigSupply,
HAL_PWREx_ControlVoltageScaling, HAL_RCC_OscConfig (first HSI block),
HAL_RCC_ClockConfig (HSI clock switch), HAL_RCC_OscConfig (HSE/PLL bring-up),
HAL_RCC_ClockConfig (PLL distribution), and HAL_RCCEx_PeriphCLKConfig, store a
unique byte/word identifier into the .bf_obl_dbg area (use distinct values per
location) and ensure the write is non-blocking/simple memory write so it will
persist through the spin; keep the existing while (1); spins unchanged
otherwise. Use the .bf_obl_dbg symbol and SystemClock_Config/HAL_* function
names to find the spots and pick unique markers for each failure path.

---

121-142: ⚡ Quick win

Magic addresses for secure-alias RCC / DBGMCU — promote to named defines.

The literals 0x56028A48, 0x56028248, 0x56028A44, 0x56028244, 0x54001004 (and bit positions (1<<0)..(1<<20) for DBGMCU.CR) are repeated verbatim at lines 134-142 and again at lines 295-301 after the clock-reconfig re-assert. The comments at lines 123-133 carry the only documentation for what each address/bit means. A single block of #defines at the top of the file (or in platform.h) eliminates the duplication, the typo risk, and makes the comment-as-documentation actually link to symbols that will outlive future re-reads.

♻️ Sketch

+// Secure-alias register accesses (RIFSC-gated; HAL/CMSIS macros emit NS aliases
+// that get silently dropped in the no-mcmse build). See OBL's system_stm32n6xx_obl.c
+// for the matching writes.
+#define RCC_S_MISCENSR      (*(volatile uint32_t *)0x56028A48UL)
+#define RCC_S_MISCENR       (*(volatile uint32_t *)0x56028248UL)
+#define RCC_S_BUSENSR       (*(volatile uint32_t *)0x56028A44UL)
+#define RCC_S_BUSENR        (*(volatile uint32_t *)0x56028244UL)
+#define DBGMCU_S_CR         (*(volatile uint32_t *)0x54001004UL)
+#define DBGMCU_CR_DBGCLKEN  (1UL << 20)
+#define DBGMCU_CR_DBG_SLEEP (1UL <<  0)
+#define DBGMCU_CR_DBG_STOP  (1UL <<  1)
+#define DBGMCU_CR_DBG_STBY  (1UL <<  2)
+#define RCC_BUSENSR_APB3ENS (1UL << 10)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/system_stm32n6xx.c` around lines 121 - 142, The magic
secure-alias addresses and DBGMCU.CR bit positions used in systemInit (and later
re-assert) are hard-coded and duplicated; create clear named constants (e.g.,
RCC_S_MISCENSR_SECURE_ALIAS, RCC_S_MISCENR_NS_ALIAS, RCC_S_BUSENSR_SECURE_ALIAS,
RCC_S_BUSENR_NS_ALIAS, DBGMCU_S_CR_SECURE_ALIAS and
DBGMCU_CR_DBGCLKEN/DBG_SLEEP/DBG_STOP/DBG_STANDBY bit masks) at the top of this
file or in the platform header, replace the literal constants and (1<<N)
expressions in systemInit and the re-assert block with those defines, and update
the existing comment to reference the new symbols so the meanings aren’t lost
and duplication/typo risk is removed (use the existing systemInit and re-assert
code locations to find all occurrences).

src/platform/STM32/link/STM32N657XX_RAM.ld (2)

223-233: ⚡ Quick win

.DMA_RW_D2 missing NOLOAD — inconsistent with XIP/FSBL variants.

STM32N657XX_XIP.ld (line 260) and STM32N657XX_FSBL_FULL.ld (line 228) both mark this section (NOLOAD); this one does not. Practically benign for an empty section, but gdb will zero-fill the D2_RAM region on load when this script is used, and any future input section landing in .DMA_RW would gain unexpected initializer bytes embedded in the .elf.

♻️ Proposed fix

-  .DMA_RW_D2 :
+  .DMA_RW_D2 (NOLOAD) :
   {
     . = ALIGN(32);
     PROVIDE(dmarw_start = .);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/link/STM32N657XX_RAM.ld` around lines 223 - 233, The
.DMA_RW_D2 output section should be marked NOLOAD to match the XIP/FSBL variants
and prevent gdb from zero-filling D2_RAM or embedding unexpected initializers;
update the linker script section definition for ".DMA_RW_D2" (the block that
sets PROVIDE(dmarw_start), _sdmarw, _dmarw_start__, KEEP(*(.DMA_RW)),
PROVIDE(dmarw_end), _edmarw, _dmarw_end__) to include the NOLOAD attribute while
keeping the existing alignment and >D2_RAM placement.

---

40-46: 💤 Low value

__config_start aliased to eepromData — couple the 4096 size to the array.

__config_end - __config_start = 4096 is hardcoded here while the actual eepromData[] size lives in C. If anyone tweaks EEPROM_SIZE without updating this script, isEEPROMStructureValid() walks past the array into adjacent .bss / .sram2. A _Static_assert(sizeof(eepromData) == EEPROM_SIZE, ...) near the array definition catches the drift at compile time, and there's a per-PR known caveat already noted in the PR objectives that CONFIG_IN_RAM saves aren't persistent across NVIC_SystemReset().

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/link/STM32N657XX_RAM.ld` around lines 40 - 46, The linker
hardcodes 4096 for __config_end which can drift from the actual eepromData[]
size; instead expose the array size from C and use that symbol in the linker.
Add a C definition like `const unsigned long __eeprom_size = EEPROM_SIZE;` (or
use sizeof(eepromData) with a _Static_assert) and then change the linker
expressions for __config_start / __config_end to use ABSOLUTE(eepromData) and
ABSOLUTE(eepromData) + __eeprom_size (referencing symbols __config_start,
__config_end, eepromData, and __eeprom_size) so the linker-bound range always
matches the real array size.

src/platform/STM32/link/STM32N657XX_FSBL_FULL.ld (1)

26-58: 💤 Low value

LOAD_RAM length is a magic 521728 — explain or derive.

Line 33: LENGTH = 521728. This is 512K - 0x400 (the boot-ROM header offset), but a reader has to do the arithmetic. Using 512K - 0x400 or a small _FSBL_HEADER_SIZE = 0x400; symbol makes the intent self-documenting and protects against silent breakage if anyone changes ORIGIN.

♻️ Proposed fix

-    /* Loaded image — boot ROM lands the .stm32 payload here. AXISRAM2
-     * runs from 0x34100000-0x341FFFFF; the FSBL slot starts at the 0x80400
-     * boot-ROM offset, leaving 521 728 bytes (509 KiB) of usable space. */
-    LOAD_RAM (rwx)    : ORIGIN = 0x34180400, LENGTH = 521728
+    /* Loaded image — boot ROM lands the .stm32 payload here. AXISRAM2 runs
+     * from 0x34100000-0x341FFFFF; the FSBL slot starts at the 0x80400
+     * boot-ROM header offset, leaving 509 KiB of usable space. */
+    LOAD_RAM (rwx)    : ORIGIN = 0x34180400, LENGTH = (512K - 0x400)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/link/STM32N657XX_FSBL_FULL.ld` around lines 26 - 58, The
LENGTH value for LOAD_RAM is a magic number (521728) representing 512K minus the
FSBL header offset; replace the hardcoded 521728 with a self-documenting
expression or symbol (e.g., define _FSBL_HEADER_SIZE = 0x400 or an equivalent
_FSBL_SLOT_OFFSET) and compute LENGTH as 512K - _FSBL_HEADER_SIZE (or
ORIGIN-dependent calculation) in the MEMORY entry for LOAD_RAM so the intent is
clear and changes to offsets won’t silently break; update the comment near
LOAD_RAM/ORIGIN (and any related symbols like LOAD_RAM, ORIGIN, or the new
_FSBL_HEADER_SIZE) to reflect the derivation.

src/platform/STM32/startup/startup_stm32n657xx.s (3)

131-141: 💤 Low value

AXISRAM-clock-enable bitmask 0x18F — same job is done again in systemInit(); the duplication is justified but worth a one-line note.

The startup pre-enables AXISRAM1..6 here at the NS alias (0x46028A4C), then system_stm32n6xx.c:275-280 re-enables each one individually through CMSIS macros. Both writes are needed (this one so the .bss zero loop doesn't fault before any C runs; the C-side one to also touch the secure alias path for HAL bookkeeping), but a future reader will rightly ask "why twice?". Add a cross-reference:

 /* Enable AXISRAM1..6 clocks before any AXISRAM1+ store. The boot ROM only
  * clocks AXISRAM2 when it hands off to a signed FSBL; .bss, the stack and
  * the DMA-capable regions live in AXISRAM1 / AXISRAM3+ and the next loop
  * (.bss zero) faults if the RAM is unclocked. Idempotent for the FSBL-stub
  * handoff and SWD-load paths where AXISRAM1 is already clocked. Writes
  * RCC->MEMENSR via the NS alias (0x4602_8A4C); the register itself is
- * shared regardless of alias. */
+ * shared regardless of alias.
+ *
+ * NOTE: systemInit() in system_stm32n6xx.c re-enables these individually
+ * through CMSIS macros — this pre-enable is mandatory only here because
+ * the .bss zero loop below executes before any C code runs. */
   ldr   r2, =0x46028A4C
   ldr   r3, =0x0000018F   /* AXISRAM3..6 (b3:0) | AXISRAM1 (b7) | AXISRAM2 (b8) */

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/startup/startup_stm32n657xx.s` around lines 131 - 141, Add
a one-line comment immediately above the "post-AXISRAM-clock-enable" write (the
ldr/str sequence to 0x46028A4C setting 0x0000018F) explaining that this
non-secure-side bulk AXISRAM1..6 enable is required so the .bss zeroing in early
startup won't fault, and that systemInit() later re-enables each AXISRAM via
CMSIS macros (see systemInit) to also touch the secure alias for HAL
bookkeeping—this cross-reference clarifies why the same 0x18F mask is written
twice.

---

58-87: 💤 Low value

NVIC clear loop hardcodes r3 = #16`` — Cortex-M55 has 8 implemented ICER/ICPR registers; tail writes are wasted but harmless.

Cortex-M55 with up to 480 IRQs uses up to 15 ICER registers; the N6 CMSIS header (stm32n657xx.h) declares ICER[16] (CMSIS standard array size), so 16 iterations is what the C-side sizeof(NVIC->ICER)/sizeof(...) in system_stm32n6xx.c:163 resolves to. The two are consistent in count but inconsistent in how the count is expressed. For a small DX win, define it once:

♻️ Sketch

+  /* Match CMSIS ICER[]/ICPR[] array size — see core_cm55.h */
+  .equ NVIC_REGS, 16
   cpsid i
   movs  r0, `#0`
   ldr   r1, =0xFFFFFFFF
   ldr   r2, =0xE000E180   /* NVIC_ICER0 */
-  movs  r3, `#16`
+  movs  r3, `#NVIC_REGS`
   ...
   ldr   r2, =0xE000E280   /* NVIC_ICPR0 */
-  movs  r3, `#16`
+  movs  r3, `#NVIC_REGS`

Also, the comments "clear ISER[i]" (line 69) and "clear ISPR[i]" (line 76) describe the effect (Set-Enable / Set-Pending gets cleared), but the registers being written are ICER / ICPR. Worth a one-word tweak for the next reader:

-  str   r1, [r2]          /* clear ISER[i] */
+  str   r1, [r2]          /* write ICER[i] → clears ISER[i] enable bits */

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/startup/startup_stm32n657xx.s` around lines 58 - 87,
Introduce a single named constant for the NVIC register count and use it instead
of hardcoding "movs r3, `#16`", and tweak the two comments to refer to ICER/ICPR
(the registers being written) rather than ISER/ISPR: add an assembly constant
(e.g. NVIC_REG_COUNT = 16) and load it into r3 before the two loops that write
0xE000E180 (NVIC_ICER0) and 0xE000E280 (NVIC_ICPR0), replace the two "clear
ISER[i]" / "clear ISPR[i]" comments with "clear ICER[i]" / "clear ICPR[i]" so
the code uses one authoritative count symbol (used by both loops) and the
comments accurately describe the registers being written.

---

93-122: ⚡ Quick win

Debug-marker base address 0x24100000 is duplicated between this file and the linker scripts — wire it through a single symbol.

STM32N657XX_XIP.ld:52 declares DBG_RAM at 0x24100000 (and STM32N657XX_FSBL_FULL.ld / _RAM.ld need to match the OBL @DBGRAM DFU alt). This startup file hardcodes the same base (and the offsets 0x80, 0x100, 0x104, 0x108, 0x10C, 0x110, 0x120) again. If DBG_RAM's ORIGIN ever moves (e.g. another secure/non-secure alias re-org), the linker, OBL, and this startup all drift independently.

Export the base from the linker script and load via PC-relative literal:

♻️ Sketch

In STM32N657XX_XIP.ld (and FSBL/RAM):

     DBG_RAM (rw)      : ORIGIN = 0x24100000, LENGTH = 512
+    /* exported so startup/OBL share the base */
+    __dbg_ram_base = 0x24100000;

In startup:

-  ldr   r3, =0xCABA0001
-  ldr   r2, =0x24100000
+  ldr   r2, =__dbg_ram_base
+  ldr   r3, =0xCABA0001
   str   r3, [r2]
-  ldr   r2, =0x24100080
+  add   r2, r2, `#0x80`
   str   r3, [r2]
   ...

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/startup/startup_stm32n657xx.s` around lines 93 - 122,
Replace the hardcoded debug RAM base and offsets with the linker-exported
DBG_RAM symbol so the startup stays in sync with the linker scripts; in
startup_stm32n657xx.s (the block that writes CABA0001 and the self-PC), load the
base via a PC-relative literal referencing DBG_RAM (e.g., use LDR r2, =DBG_RAM)
and then write to DBG_RAM+0x80, DBG_RAM+0x100, +0x104, +0x108, +0x10C, +0x110
and store the PC to DBG_RAM+0x120 instead of using 0x24100000 and the hardcoded
offsets, ensuring the symbol name DBG_RAM is used for all addresses so any
ORIGIN change in STM32N657XX_XIP.ld (and matching FSBL/RAM/OBL) stays
consistent.

src/platform/STM32/link/STM32N657XX_XIP.ld (1)

145-196: ⚡ Quick win

Contiguity requirement is implicit — add an ASSERT to fail builds early.

The copy at Reset_Handler walks _stext.._etext and reads from _sitext (= LOADADDR(.ram_code)), assuming .ram_code → .data → .fastram_data → .dmaram_data are perfectly contiguous in both VMA and LMA with no gaps. Any future re-ordering or inserted section (NOLOAD or XIP-only) silently breaks the copy and produces a corrupt image — the comment at lines 135-141 is the only safeguard.

A linker ASSERT makes this enforcement compile-time:

♻️ Proposed safety net

   .dmaram_data :
   {
     . = ALIGN(32);
     PROVIDE(dmaram_start = .);
     _sdmaram = .;
     _dmaram_start__ = _sdmaram;
     _sdmaram_data = .;
     *(.dmaram_data)
     *(.dmaram_data*)
     . = ALIGN(32);
     _edmaram_data = .;
     _etext = .;
   } >RAM AT >FLASH
+
+  ASSERT((_etext - _stext) == (LOADADDR(.dmaram_data) + SIZEOF(.dmaram_data) - LOADADDR(.ram_code)),
+         "XIP: VMA span (_stext.._etext) must equal LMA span; non-contiguous copy region detected")

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/platform/STM32/link/STM32N657XX_XIP.ld` around lines 145 - 196, Add a
linker-time ASSERT to ensure .ram_code, .data, .fastram_data and .dmaram_data
are contiguous in memory so the Reset_Handler copy from _stext.._etext using
ram_code (LOADADDR(.ram_code) / _sitext) cannot be broken by future reordering;
specifically assert that ram_code_end == LOADADDR(.data) (or that ram_code_start
+ SIZEOF(.ram_code) == LOADADDR(.data)) and that the end of .data equals
LOADADDR(.fastram_data) (or _efastram_data == LOADADDR(.fastram_data)) and that
the end of .fastram_data equals LOADADDR(.dmaram_data) (or _edmaram_data ==
LOADADDR(.dmaram_data)), using the existing symbols ram_code_start,
ram_code_end, ram_code, _stext, _etext, _sfastram_data/_efastram_data and
_sdmaram/_edmaram_data so the build fails if any gap exists.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes