Hello,
Yes, the inability to write individual bits in already programmed
sectors is a HUGE constraint. We have flash like this in some high
security embedded products, and it required a full redesign of our flash
interface.
Wear leveling is doable, but the particular bit that made us think
*very* hard was the interruption recovery. Which is critical in any
embedded product where the battery can be removed any time.
This stuff is not trivial at all. If you find an easy solution, then
test it over 9000 times under load stress, because it might be the wrong
solution.
Remember, flash memory is analog, bits are just a bunch of electrons in
a floating gate, and their value is determined by thresholds, that
change with temperature and the age of the captain.
Any interruption can result in half-written or half-erased bits, that
are unstable and change value at each read.
Sebastien
On 25/05/2024 21:38, Gregory Nutt wrote:
> Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
> remember correctly, he never got it well tested because there is no
FS for
> NAND on NuttX.
I did test the FS's that were available and they mostly worked on
these platforms. I could actually run nxffs and smartfs for a long
while before they failed. They failed because the FSs that I looked at
assumed that you can always write a "1" to a "0". Actually, you can do
that but this then results in ECC error. Even a single bit 1=>0 change
requires a full erase, re-writing the ECC, and a full sector write.
As I recall, nxffs would write some single "0" bits to indicate sector
state changes; SmartFS had a small counter that was used to manage
wear leveling.
> I think if you decide to use an SPI NAND Flash with ECC and bad block
> support in HW it will be easier to test your FS, in this case even
LittleFS
> could work:
> https://github.com/littlefs-project/littlefs/issues/11
Sparing and wear-leveling would also be needed.
> But later on we will need to get ECC and bad block table support on
NuttX
> to validate your FS with some native NAND Flash controller.
I think that software bad block and ECC are already supported and
verified (but it has been awhile since I used them). Sparing, and
wear-leveling are normally done by an FTL, but can be done by the file
system. Bad block detection and ECC may be done by hardware, FTL, or
higher level software. Then the only outstanding issues are finding
such an FTL and a file system that does not do read-modify-write
operations without updating the ECC.
LittleFS was a candidate a few years ago and required a special FTL to
get all of these features. Maybe that has changed in more recent
versions.
