target/lpc4088qsb: fix page_size mismatch causing silent flash corruption#2015
Open
alramlechner wants to merge 1 commit into
Open
target/lpc4088qsb: fix page_size mismatch causing silent flash corruption#2015alramlechner wants to merge 1 commit into
alramlechner wants to merge 1 commit into
Conversation
…tion The FlashRegion for the main flash bank (start=0x10000, >64 KB) declared page_size=0x400, but the referenced INTERNAL_FLASH_ALGO (shared with target_LPC4088FBD144, which correctly uses page_size=0x200 for the equivalent region) only implements 512-byte pages: its own 'page_size'/ 'min_program_length' are 0x200/512, and page_buffers holds a single 512-byte buffer. With page_size=0x400, pyOCD's flash loader chunks writes into 1 KB pages, but the flash algo's program_page() call only programs the first 512 bytes of each chunk and silently drops the rest -- no error is raised. Any image whose .bin crosses the 64 KB boundary and is not an exact multiple of 1 KB in that region ends up with 512-byte holes left at the erased value, corrupting whatever data lands there (e.g. an .data initializer image, if the linked image happens to end mid-page). Confirmed via readback (savemem + binary diff) against a LPC4088-based board: flashing a ~65.6 KB image left the trailing partial page unprogrammed at the erased value, while pyocd reported success.
alramlechner
force-pushed
the
fix/lpc4088qsb-page-size
branch
from
July 24, 2026 10:31
c58df60 to
63aeea7
Compare
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.
Summary
target_lpc4088qsb.py'sFlashRegionfor the main flash bank (start=0x10000,>64 KB) declares
page_size=0x400, but theINTERNAL_FLASH_ALGOit uses(shared with
target_LPC4088FBD144, which correctly declarespage_size=0x200for the equivalent region) only implements 512-byte pages: its own
page_size/min_program_lengthare0x200/512, andpage_buffersholds asingle 512-byte buffer.
With
page_size=0x400, the flash loader chunks writes into 1 KB pages, butprogram_page()only programs the first 512 bytes of each chunk and silentlydrops the rest — no error is raised. Any image whose
.bincrosses the 64 KBboundary and isn't an exact multiple of 1 KB in that region ends up with
512-byte holes left at the erased value.
How I found this
Debugging a board that ran fine until its firmware image grew past 64 KB,
after which it intermittently corrupted RAM depending on exact build layout.
Confirmed via readback (
pyocd commandersavemem+ binary diff): a ~65.6 KBimage left a 512-byte hole unprogrammed (still
0xFF) right at the boundary,while
pyocd flashreported success with no warning.Fix
Change
page_sizefor that region from0x400to0x200, matching theflash algo and the sibling target
target_LPC4088FBD144.py.Testing
Re-flashed the same image after the fix; readback matched the source
.binexactly, and the target (LPC4088-based board) now runs correctly.