fix(linker): correct RAM start address for Mac_802_15_4 IAR/Keil projects#118
Open
94xhn wants to merge 1 commit into
Open
fix(linker): correct RAM start address for Mac_802_15_4 IAR/Keil projects#11894xhn wants to merge 1 commit into
94xhn wants to merge 1 commit into
Conversation
…ects The 5 Mac_802_15_4_* example projects (Coordinator, FFD, Node, RFD, LPM_Periodic_Transmit) declare the CPU2-shared RAM1 region inconsistently across toolchains: GCC (STM32CubeIDE/*.ld): RAM1 ORIGIN = 0x20000008, LENGTH = 0x2FFF8 IAR (EWARM/*.icf): RAM_start = 0x20020000 (before this fix) Keil (MDK-ARM/*.sct): RW_IRAM1 = 0x20020000, size 0x10000 (before this fix) GCC users get the (correct) full RAM1 extent (~192KB, from 0x20000008 up to the RAM_SHARED region at 0x20030000), while IAR and Keil users only got the last 64KB (0x20020000-0x2002FFFF) - the first 128KB of RAM1 was simply never declared as usable for those two toolchains, even though the same physical memory is being used by the GCC build of the exact same example. The other WB55 projects in this repo (e.g. Projects/P-NUCLEO-WB55.Nucleo/Templates) already correctly declare RAM_start as 0x20000008 for IAR - confirming this is the correct value and the Mac_802_15_4 family's IAR/Keil linker files are the outliers, not an intentional restriction. Fix: align the IAR (*.icf) and Keil (*.sct) linker files' RAM1 start address/size with the already-correct GCC (*.ld) and Templates project values. Mac_802_15_4_LPM_Periodic_Transmit's Keil file was already correct, so only its IAR file needed the fix. Signed-off-by: 94xhn <87560781+94xhn@users.noreply.github.com>
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
1 participant
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.
Problem
This isn't reported as a GitHub issue - I found it by cross-checking the RAM region declared for the same example across its three toolchain variants (GCC/IAR/Keil), after noticing STM32CubeG4 had a similar toolchain-inconsistency bug in its linker scripts (see #57 in that repo).
The 5
Mac_802_15_4_*example projects (Coordinator,FFD,Node,RFD,LPM_Periodic_Transmit) underProjects/P-NUCLEO-WB55.Nucleo/Applications/Mac_802_15_4/declare the RAM1 region inconsistently across toolchains:*.ldORIGIN = 0x20000008, LENGTH = 0x2FFF8(correct, ~192KB)EWARM/*.icfRAM_start = 0x20020000(only the last 64KB)MDK-ARM/*.sctRW_IRAM1 0x20020000 0x10000(only the last 64KB)So GCC users of these exact same examples get the full RAM1 extent, while IAR and Keil users silently only get the last 64KB - the first 128KB of RAM1 (2/3 of it) was never declared as usable in their linker files, even though it's the same physical memory used by the GCC build.
Verification
I cross-checked against
Projects/P-NUCLEO-WB55.Nucleo/Templates/EWARM/stm32wb55xx_flash_cm4.icf(a non-suspect project for the same MCU), which already correctly declares__ICFEDIT_region_RAM_start__ = 0x20000008- confirming 0x20000008 is the correct, intended value across the repo, and the Mac_802_15_4 family's IAR/Keil files are the outliers.Mac_802_15_4_LPM_Periodic_Transmit's Keil (.sct) file was actually already correct (0x20000008 0x2FFF8) - only its IAR file had the wrong value, unlike the other 4 projects where both IAR and Keil were wrong. This inconsistency between the 5 projects (4 wrong in both toolchains, 1 wrong in only one) is itself evidence this is an unintentional drift between toolchain-specific linker file copies, not a deliberate restriction.Fix
Align the IAR (
*.icf) and Keil (*.sct) RAM1 start address/size with the already-correct GCC (*.ld) andTemplatesproject values, across all 5 affected projects (9 files total: 5.icf+ 4.sct, sinceLPM_Periodic_Transmit's.sctneeded no change).Disclosure
Generative AI (Claude) was used to help investigate this issue (cross-toolchain linker script comparison) and script the fix. All changes were reviewed by me before submission.