littlefs Integration - ECC Fails with Blank Buffer if Initial Values are not Zero

[dhughes-gh]

I'm trying to implement the ECC correction demonstrated in this project for a flash based block device used by LittleFS.

The major difference between the samples in this repository and a flash device in hardware is the default value of the bytes (0x00 in the examples in RAM, and 0xFF in flash hardware). To emulate this, I changed the default state of the RAM buffer to contain 0xFF in each location and implemented an erase handler for ramrsbd that resets buffer positions to 0xFF.

When using the ramrsbd with this modified buffer in littlefs, lfs_open_file is returning error LFS_ERR_CORRUPT because the block device read function is failing when it calculates non-zero syndromes on the "blank" areas.

Is there a recommended way to deal with this so that littlefs can use the ECC correction from this project in custom block devices?

[dhughes-gh]

Turns out brute force checking if the values are all equal to 0xFF in the code word might be sufficient. A code of that value is corrupt beyond a practical amount of byte errors. At least in my case the occurrence of that erased value being a valid empty area is sufficient. Later writes and reads to erased memory will validate the hardware or byte errors correctly.

[geky]

Hi @dhughes-gh, thanks for creating an issue, sorry for the late response.

I'm going to go ahead and reopen this, it sounds like a potential bug in littlefs.

In theory, the way things work is bd reports LFS_ERR_CORRUPT -> littlefs treats the block as uninitialized. If that bubbles up through lfs_file_open, then something is wrong.

Even if the ECC corrects to the "wrong" codeword, it's unlikely the block will then pass littlefs's CRC checks.