2024-05-22 09:14 AM - edited 2024-05-22 09:17 AM
Does erasing an already-erased Flash page contribute to wear?
Reason for asking: the EEPROM emulation code erases pages which should already be erased without checking that they are already erased - is that just laziness, or is it because there is actually no/negligible wear from erasing an already-erased page?
EDIT:
Looks like it probably does:
2024-05-22 09:40 AM - edited 2024-05-22 09:42 AM
Tends to depend on the exact implementation, some of the more self-timed one aren't discharging/charging if the cell isn't in need of that occurring. Micron QSPI NOR for example complete a lot faster if the blocks/part are already blank.
ST doesn't allow for multiple knock-down writes, where you zero out the cells before erasing, so the charge levels are equalized, a technique used to reduce "memory" / ghosting, where prior content persists at some much reduced level.
In ST's designs a lot of the wear/stress seems to be with the charge-pump and the life there with the stresses from higher voltages.
@STOne-32 any white papers on the various flash arrays, geometries/processes?
Probably laziness or simplicity. Now, with much of my update code I tend to explicitly blank check before doing an erase, but this is more to improve the perceived speed of operation, a read/check is very fast, and will terminate early if content seen, whereas erasing usually takes an age, especially with larger blocks/sectors.
The ECC methods may imped the ability to check erased/virgin state on flash lines.
2024-05-23 02:20 AM - edited 2024-05-23 03:30 AM
@Tesla DeLorean wrote:a read/check is very fast, and will terminate early if content seen, whereas erasing usually takes an age
Indeed. Especially in the case of the EEPROM emulation, where the whole thing relies on content being written from low-to-high addresses - so any content should be seen early in the search.
And now another question occurs: I guess a blank-check would consume (a lot?) less power than an erase?