Repository navigation
stm32u5: skip programming quad-words that are erased and stay erased - #944
Merged
Merged
Conversation
Programming takes about 120 us per 16-byte unit at 160 MHz, so writing an 8 KB sector takes about 62 ms whatever it holds. The PKCS#11 store commits whole sectors, twice each with the backup sector, and they are mostly erased. Skip a unit when both the new data and the flash are all 0xFF. The flash content is the same, and the unit can still be programmed later.
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
The new branch lacks automated regression coverage, and firmware-update swap behavior remains unvalidated.
1 open finding
What changed in this PR
Optimizes STM32U5 flash writes to reduce time spent programming mostly erased sectors, including PKCS#11 storage commits.
Changes:
- Skips 16-byte quad-words when both requested data and existing flash are all
0xFF. - Advances past skipped units without enabling flash programming.
| File | Description |
|---|---|
hal/stm32u5.c |
Adds the erased-quad-word skip to hal_flash_write(). |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Readback cannot tell a skipped unit from one programmed with 0xFF, so the mock hal_flash_wait_complete() now counts program operations (waits with FLASH_CR_PG set). New tests check that erased data over erased flash is not programmed (aligned and unaligned), that only the units with data are programmed when erased and data units are mixed, and that units are still programmed for data inside an erased unit, for 0xFF over flash that is not erased, and for 0xFF in a unit that holds data outside the request. The three skip tests fail on the HAL without the skip.
danielinux
approved these changes
Oct 16, 2026
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.
On STM32U5, programming takes about 120 us per 16-byte quad-word at 160 MHz, whatever the data. On an STM32U585 an 8 KB page takes 61.6 ms to program and 0.87 ms to erase. The PKCS#11 store (
src/pkcs11_store.c) commits whole 8 KB sectors, each twice (the backup sector, then the destination), and those sectors are mostly erased. Most of the commit time therefore goes into programming0xFF.hal_flash_write()now skips a quad-word when both the new data and the current flash content are all0xFF. The flash ends up the same, and the quad-word stays erased, so it can still be programmed later.Testing on an STM32U585 board (TZEN=1,
stm32u5-wolfcrypt-tz.config):FLASH_NSSR. The skipped quad-words can be programmed afterwards (2 KB aligned, 3 unaligned bytes, and a single quad-word between programmed ones), and they read back correctly.Not covered: the update swap path. With this config I could not get a staged update applied on unmodified master either, so I had no baseline to compare against.