Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
TDBStore bugfix: won't rely on flash erase value to detect is a sector erased #11349
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.
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
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.
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
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).