fix(linker): correct cross-toolchain memory map inconsistencies - #39
Open
94xhn wants to merge 1 commit into
Open
fix(linker): correct cross-toolchain memory map inconsistencies#3994xhn wants to merge 1 commit into
94xhn wants to merge 1 commit into
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
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 in this repo family. 1. Demonstrations (32L0538DISCOVERY, STM32L053C8, 64K flash): GCC's .ld declares FLASH LENGTH=192K - directly contradicting its own doc-comment header two lines above, which correctly says "64Kbytes FLASH". IAR's .icf and Keil's <Device>STM32L053C8Tx</Device>/OCR both correctly use 64K, matching this board's Templates project. Fixed GCC's .ld to 64K. 2. Applications/IAP/IAP_Binary_Template (STM32L073Z-EVAL, STM32L073VZ, 192K flash): both GCC's .ld and Keil's .uvprojx correctly offset the app's flash start address to 0x08005000 to leave room for the bootloader, but neither shrinks the length to compensate - both still declare 192K as if starting from 0x08000000, running 20K past the chip's actual end of flash. IAR's .icf correctly uses 172K (0x08005000-0x0802FFFF). 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. Fixed GCC's .ld and Keil's OCR_RVCT4 Size to 172K (0x2B000), matching IAR. Two further candidates (Examples/FIREWALL/FIREWALL_VolatileData_Executable and FIREWALL_VolatileData_Shared, same board) were investigated but not included here: each demo uses a genuinely different, hand-tuned memory partition per toolchain to exercise the STM32L0 FIREWALL peripheral's protected-segment feature (e.g. IAR's "ROM"/"RAM" region names refer to small SRAM-resident protected zones in one variant, and a mix of small flash regions plus a separate protected sub-region in the other) - this isn't the toolchain-drift pattern the other fixes address, and verifying the "correct" partition would require deeper FIREWALL peripheral domain knowledge than I have confidence in, so I left them alone rather than guess. 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>
Copy link
Copy Markdown
Contributor
|
Hello @94xhn, Thank you for these fixes. This has been tracked internally. With Regards, |
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
|
ST Internal Reference: 49a94e58f85e47105d7b8396f8a7b070 |
Sorry, something went wrong.
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
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 Templates sibling projects for the same chip, following the same methodology already used for STM32CubeG4, STM32CubeWB, STM32CubeWL, STM32CubeU5, STM32CubeF7, STM32CubeF4, STM32CubeL4, STM32CubeH7, and STM32CubeF1 in this repo family.
1. Demonstrations (32L0538DISCOVERY, STM32L053C8, 64K flash) - GCC contradicts its own doc comment
GCC's .ld declares FLASH LENGTH=192K - directly contradicting its own doc-comment header two lines above, which correctly says 64Kbytes FLASH. IAR's .icf and Keil's <Device>STM32L053C8Tx</Device>/OCR_RVCT4 both correctly use 64K, matching this board's Templates project. Fixed GCC's .ld to 64K.
2. Applications/IAP/IAP_Binary_Template (STM32L073Z-EVAL, STM32L073VZ, 192K flash) - GCC and Keil both offset the start but forget to shrink the length
Both GCC's .ld and Keil's .uvprojx correctly offset the app's flash start address to 0x08005000 to leave room for the bootloader, but neither shrinks the length to compensate - both still declare 192K as if starting from 0x08000000, running 20K past the chip's actual end of flash. IAR's .icf correctly uses 172K (0x08005000-0x0802FFFF).
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. Fixed GCC's .ld and Keil's OCR_RVCT4 Size to 172K (0x2B000), matching IAR.
Scope note
Two further candidates on the same board (Examples/FIREWALL/FIREWALL_VolatileData_Executable and FIREWALL_VolatileData_Shared) were investigated but are not included here: each demo uses a genuinely different, hand-tuned memory partition per toolchain to exercise the STM32L0 FIREWALL peripheral's protected-segment feature (e.g. IAR's "ROM"/"RAM" region names refer to small SRAM-resident protected zones in one variant, and a mix of small flash regions plus a separate protected sub-region in the other). This isn't the toolchain-drift pattern the fixes above address, and verifying what the "correct" partition should be would need deeper FIREWALL peripheral domain knowledge than I have confidence in, so I left them alone rather than guess.
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: Templates gold 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.