fix(linker): correct cross-toolchain memory map inconsistencies#24
Open
94xhn wants to merge 1 commit into
Open
fix(linker): correct cross-toolchain memory map inconsistencies#2494xhn wants to merge 1 commit into
94xhn wants to merge 1 commit into
Conversation
Found by cross-checking each example's GCC (SW4STM32)/IAR (EWARM)/Keil (MDK-ARM) linker scripts against each other and against known-good Templates sibling projects, following the same audit already done for STM32CubeG4/WB/WL/U5/F7/F4/L4/H7/F1/L0 in this repo family. 1. Applications/USB_Device/DFU_Standalone/Binary/binary_template (STM32072B_EVAL, STM32F072VBTx, 128K flash): GCC's .ld and Keil's .uvprojx both correctly offset the app's flash start address to 0x08007000 to leave room for the bootloader, but neither shrinks the length to compensate - both still declare 128K as if starting from 0x08000000, running 28K past the chip's actual end of flash. IAR's .icf correctly uses 100K (0x08007000-0x0801FFFF). Fixed GCC's .ld and Keil's OCR_RVCT4 Size to 100K (0x19000), matching IAR. 2. Applications/USB_Device/DFU_Standalone/Binary/binary_template (STM32F072B-Discovery, STM32F072RBTx, 128K flash): identical bug as STMicroelectronics#1 above, same board family, same fix (128K -> 100K on GCC's .ld and Keil's OCR_RVCT4 Size). 3. Examples/IWDG/IWDG_WindowMode (STM32F070RB-Nucleo, STM32F070RB, 128K flash / 16K RAM): IAR's .icf alone declares only 64K flash and 8K RAM - half of the chip's actual capacity, and half of what GCC's .ld, Keil's OCR_RVCT4, and this board's own Templates project all agree on. Fixed IAR's .icf region end symbols to 0x0801FFFF (128K flash) and 0x20003FFF (16K RAM). No local ARM toolchain (arm-none-eabi-gcc/IAR/Keil) available to compile/link-test these changes; verification relied on address-arithmetic cross-referencing against multiple independent references per finding (Templates gold standards, sibling toolchain files of the same project, and the Keil <Device> tag naming the actual target chip). Signed-off-by: 94xhn <87560781+94xhn@users.noreply.github.com>
ALABSTM
added
bug
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Not tied to a specific existing issue - found by systematically cross-checking each example's GCC (SW4STM32)/IAR (EWARM)/Keil (MDK-ARM) linker scripts against each other and against known-good
Templatessibling projects for the same chip, following the same methodology already used for STM32CubeG4, STM32CubeWB, STM32CubeWL, STM32CubeU5, STM32CubeF7, STM32CubeF4, STM32CubeL4, STM32CubeH7, STM32CubeF1, and STM32CubeL0 in this repo family.1.
Applications/USB_Device/DFU_Standalone/Binary/binary_template(STM32072B_EVAL, STM32F072VBTx, 128K flash) - GCC and Keil both offset the start but forget to shrink the lengthBoth GCC's
.ldand Keil's.uvprojxcorrectly offset the app's flash start address to0x08007000to leave room for the bootloader, but neither shrinks the length to compensate - both still declare 128K as if starting from0x08000000, running 28K past the chip's actual end of flash. IAR's.icfcorrectly uses 100K (0x08007000-0x0801FFFF).This is a "2-of-3-toolchains-wrong" case - a naive majority vote here would have picked the wrong answer, similar to what was already found in STM32CubeWB/F7/F4/H7/F1/L0. Fixed GCC's
.ldand Keil'sOCR_RVCT4Sizeto 100K (0x19000), matching IAR.2.
Applications/USB_Device/DFU_Standalone/Binary/binary_template(STM32F072B-Discovery, STM32F072RBTx, 128K flash) - identical bug, same board familySame exact pattern as finding #1: GCC's
.ldand Keil'sOCR_RVCT4both declare 128K flash length starting from the bootloader-offset address0x08007000instead of the correct 100K. Fixed identically.3.
Examples/IWDG/IWDG_WindowMode(STM32F070RB-Nucleo, STM32F070RB, 128K flash / 16K RAM) - IAR alone at half capacityIAR's
.icfdeclares only 64K flash (0x08000000-0x0800FFFF) and 8K RAM (0x20000000-0x20001FFF) - exactly half of the chip's actual capacity. GCC's.ld, Keil'sOCR_RVCT4, and this board's ownTemplatesproject all agree on the correct 128K flash / 16K RAM. Fixed IAR's.icfregion-end symbols to0x0801FFFF(128K) and0x20003FFF(16K).Test plan
No local ARM toolchain (arm-none-eabi-gcc/IAR/Keil) available to compile/link-test these, so verification relied on address-arithmetic cross-referencing against multiple independent references per finding:
Templatesgold standards, sibling toolchain files of the same project, and the Keil<Device>tag naming the actual target chip.Disclosure
Generative AI (Claude) was used to help investigate this (systematic cross-toolchain linker script comparison) and implement/verify the fixes. All changes were reviewed by me before submission.