-
Notifications
You must be signed in to change notification settings - Fork 764
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
Data Flash values after erase is "undefined" - Would LittleFS work? #969
Comments
LittleFS doesn't assume 0xFF actually, so it should work. To be exact, LittleFS requires only that subsequent reads after an erase returns the same value, or consistently returns LFS_ERR_CORRUPT. Usually when flash devices say the value after an erase is undefined, it's because they include some extra error-correction that becomes invalid after an erase. But as long as it consistently reports invalid, we can use that to detect if the block has been erased. But I would also double check the datasheet to see if they define "undefined". In theory a new storage type could put the storage into a truly unstable state on erase, but if that's the case I'm not sure it's even theoretically possible to log when power-loss is involved... Worst case, erased-state in LittleFS is checked with a checksum before use, so if the erased-state is truly unstable it just means LittleFS will erase much more often. Though depending on the underlying storage this could be impractically slow. |
I would like to know if LittleFS is designed based on the assumption that, the values of flash after erase, are '0xFF'?
I am using a family of Renesas family MCU where the values of data flash after erase is 'undefined'
Would LittleFS work on this type of MCU?
The text was updated successfully, but these errors were encountered: