-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TDBStore bugfix: won't rely on flash erase value to detect is a sector erased #11349
Conversation
When flashing a binary STLink won't skip writing padding which happens to be the same value as flash's erase value. STM32L4 based targets have an additional 8-bit of embedded ECC for each 64-bit word of data. The initial value, when a sector is erased, for the ECC bits is 0xFF. When you write the erase value to a given address these bits gets modified to something different due to the ECC algoritm in use. The visible bits are intact but difference in ECC value prevents flipping any 1's to 0's. Only way to proceed is to erase the whole sector.
@VeijoPesonen, thank you for your changes. |
@VeijoPesonen Should we drop the whole |
Hmm, this is quite interesting. There are presumably a large class of devices where Does this end up greatly increasing the number of erase cycles? Do higher levels do |
The original implementation is done by @davidsaada - PR #8667. David, what was the original reason to add the check - if a region is already erased - before actually carrying out the procedure? |
TDBStore implements an "erase as you go" method of operation. This means that instead of erasing an entire TDBStore area upon init/reset/GC, we only erase the first sector (in order to keep the area invalid), and then upon crossing sector boundaries on writes, we check whether the next sector is erased. If not - we erase it. The reason for this MO is that the alternative of erasing the whole area in advance (in the aforementioned cases) can take an unacceptably long time. Again - we don't do it on each write, but only when we cross a sector boundary (otherwise it would be very inefficient). |
@0xc0170 This is needed for 5.14. No need for more review. Separate email discussion ongoing whether this functionality has ever worked correctly, and whether we should drop it. But for now on, this immediate fix is required. |
CI started |
Test run: FAILEDSummary: 1 of 4 test jobs failed Failed test jobs:
|
Build restarted, known build issue |
Test run: FAILEDSummary: 3 of 4 test jobs failed Failed test jobs:
|
The crypto example should be fixed, CI was restarted |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Description
When flashing a binary STLink won't skip writing padding which happens to be the same value as flash's erase value. STM32L4 based targets have an additional 8-bit of embedded ECC for each 64-bit word of data. The initial value, when a sector is erased, for the ECC bits is 0xFF.
When you write the erase value to a given address these bits gets modified to something different due to the ECC algorithm in use. The visible bits are intact but difference in ECC value prevents flipping any 1's to 0's. Only way to proceed is to erase the whole sector.
Mbed OS HAL API doesn't provide a way to check is a sector erased or not. In this case code was relying on the fact that the erase value would indicate is a sector erased.
For further details please see STM32L475 Internal Flash driver write issue
Pull request type
Reviewers
@kjbracey-arm
@SeppoTakalo
@JammuKekkonen - original author of the fix.
Release Notes