fix(linker): correct cross-toolchain memory map inconsistencies

[94xhn]

Summary

Cross-toolchain audit of the linker/memory configuration files under Projects/ (GCC .ld, IAR .icf, Keil .uvprojx) for this repository, comparing the memory-region declarations for the same physical memory across the three toolchains within each project.

Finding: Keil external SRAM region under-declared in FSMC_SRAM_DataMemory

Project: Projects/STM322xG_EVAL/Examples/FSMC/FSMC_SRAM_DataMemory

This example redirects the application's data memory (heap, stack, and a test buffer) entirely into the board's external FSMC SRAM at 0x64000000, as stated in readme.txt:

"The user has to configure his preferred toolchain using the provided linker file. The RAM zone is modified in order to use the external SRAM memory as a RAM."

For GCC and IAR, both linker files declare this external region as 1 MB:

• SW4STM32/STM322xG_EVAL/STM32F207IGHx_FLASH.ld:
  RAM (xrw) : ORIGIN = 0x64000000, LENGTH = 1024K
• EWARM/stm32f207xx_extsram.icf (the file actually selected by the project via IlinkIcfOverride in Project.ewp, not the unused sibling stm32f207xx_flash.icf):
  __ICFEDIT_region_RAM_start__ = 0x64000000, __ICFEDIT_region_RAM_end__ = 0x640FFFFF → 0x100000 = 1 MB

But MDK-ARM/Project.uvprojx declared the same address, OCR_RVCT9 (Type 0 = RAM), with <Size>0x20000</Size> — only 128 KB, an 8x smaller window than the other two toolchains for the identical base address 0x64000000.

The board's external memory is an ISSI IS61WV102416BLL-10MLI SRAM (1M x 16-bit = 2 MB total capacity), so 1 MB is a sensible declared subset of the real chip, consistent between two independently-authored toolchain files (GCC and IAR). Keil's 128 KB figure has no similar justification and appears to be a stale/incorrect value.

Fix: changed OCR_RVCT9's <Size> from 0x20000 to 0x100000 in Project.uvprojx, bringing Keil's declared external-SRAM window in line with GCC and IAR for the same physical memory.

Other candidates investigated and ruled out (false positives)

• Applications/IAP/IAP_binary_template — flagged by an automated size-diff pass because its FLASH region (992 KB, starting at 0x08008000) differs from the board's Templates project (1 MB, starting at 0x08000000). Manually verified: GCC (.ld), IAR (.icf), and Keil (Project.uvprojx <Cpu> tag) all three agree on 0x08008000/992 KB — the application intentionally reserves the first 32 KB of flash for the IAP_Main bootloader. Not a bug; the mismatch is expected given the different purpose of the project versus the plain Templates project.
• RAM region "mismatch" surfaced by comparing all .icf files under FSMC_SRAM_DataMemory/EWARM — the folder contains two .icf files (stm32f207xx_flash.icf and stm32f207xx_extsram.icf); only stm32f207xx_extsram.icf is actually referenced by the project (IlinkIcfOverride in Project.ewp). The other file is vestigial/unused. Confirmed by inspecting the .ewp project file directly rather than trusting a naive per-directory scan.
• Universal 1-byte size discrepancy between every GCC .ld and IAR .icf RAM region across the entire repository (e.g. GCC declares 128 KB, IAR's computed size is 128 KB + 1 byte) — this is because IAR's __ICFEDIT_region_RAM_end__ symbol is defined as one address higher than the true last valid byte (0x20020000 instead of 0x2001FFFF) in every single project's .icf, including the board's own Templates gold reference. This is a repo-wide (and, based on prior audits of 17 sibling STM32Cube repositories, ST-wide) convention/quirk in how the ICF editor writes the RAM_end symbol, not a toolchain-specific bug — excluded as noise, not reported.
• IAP_Main bootloader project declaring a CCMRAM region (0x10000000, 64 KB) — GCC, IAR, and Keil all three agree on this region, so there is no cross-toolchain drift to report regardless of whether it reflects real silicon.

Test plan

No local ARM toolchain (GCC/arm-none-eabi, IAR EWARM, or Keil MDK) was available to build and link this project. Verification was done purely through address arithmetic cross-checked against three independent sources for each project:

• GCC linker script MEMORY regions (ORIGIN/LENGTH)
• IAR .icf __ICFEDIT_region_*_start__/_end__ symbols (cross-checked against the actual .ewp IlinkIcfOverride to confirm which .icf is the one actually used, since a project may contain more than one)
• Keil .uvprojx OCR_RVCTn (Type/StartAddress/Size) entries, cross-checked against the top-level <Cpu> tag
• The physical SRAM chip's datasheet capacity (ISSI IS61WV102416BLL, confirmed via public distributor listings) as an independent sanity check on which declared size is plausible

This same methodology (without local toolchain builds) has previously surfaced and had merged 65+ confirmed cross-toolchain linker inconsistencies across 17 other STM32Cube repositories.

Disclosure

This investigation and fix were carried out with the assistance of Claude (Anthropic AI). All findings were manually cross-checked against the raw linker/project files and the external SRAM chip's datasheet before being reported here, and every change in this PR was reviewed by me before submission.

[KRASTM]

ST Internal Reference: 9d1b6095831a8b147e8514b71eda1e9e