Corrupted dir pair at {0x0, 0x1} on a continous write to a file

[tgrero]

I've been testing a sample program to log data continuously on a littlefs file system.

I'm using Zephyr platform and 128 MB (1Gb) NOR flash from Winbond. Flash gets mounted and was also able to write some data.

On an extreme case where I wanted to test 32MB continous data log, I experience an issue where the 0,1 blocks gets corrupted half way through the writing process.

I've tested this a couple of times and the corruption seems to start at different memory addresses in both tests.

[protocentralashwin]

+1 . Facing the same issue with Zephyr on nRF Connect SDK with Winbond W25Q01JV. Mine fails after 16 MB, sometimes 32 MB. Is there a way to even recover the data recorded until then?

[tgrero]

@protocentralashwin I'm using the same flash chip. I managed to complete a 32MB dump after changing some configs in littlefs but seems to corrupt the first two blocks after the dump. I have not recovered any data yet.

Have you tested beyond 32MB and could you please share your configs to compare?

[protocentralashwin]

This is my configuration: fstab { compatible = "zephyr,fstab"; lfs1: lfs1 { compatible = "zephyr,fstab,littlefs"; mount-point = "/lfs1"; partition = <&lfs1_part>;

        read-size = <32>;
        prog-size = <32>;
        cache-size = <256>;

        lookahead-size = <64>;
        block-cycles = <0>;
    };
};

It also seems like the speed at which consecutive writes are done matter quite a bit, I was able to get it up to 32 (from 16), by not writing very fast.

[nvlsianpu]

@qudirr Is this similar to zephyr-rtos ticket https://github.com/zephyrproject-rtos/zephyr/issues/40453?

[tgrero]

This is my configuration: fstab { compatible = "zephyr,fstab"; lfs1: lfs1 { compatible = "zephyr,fstab,littlefs"; mount-point = "/lfs1"; partition = <&lfs1_part>;

      read-size = <32>;
      prog-size = <32>;
      cache-size = <256>;

      lookahead-size = <64>;
      block-cycles = <0>;
  };
};

It also seems like the speed at which consecutive writes are done matter quite a bit, I was able to get it up to 32 (from 16), by not writing very fast.

Thanks for the feedback @protocentralashwin. Even though I managed to reach 32MB it seemed to corrupt the file system just after completion which completely format the flash upon the next reset.

Were you able to preserve the files system after successfully writing 32MB? Also what was the delay you kept between writes?

[richesonk]

Do you know for certain that the NOR flash you're using is being enabled for 32-bit addressing (see zephyrproject-rtos/zephyr#40453 and https://devzone.nordicsemi.com/f/nordic-q-a/81986/littlefs-on-large-qspi-nor). Given the that your issues happens around 16MB it seems like you might be facing a similar issue. Note that this may require changes to both the driver and your DTS entry.

[protocentralashwin]

@qudirr , I am now able to write up to 48 MB without any problems consistently, but beyond, it fails 1 out of 2 times. So I'm not sure if this is related to the issue that @richesonk mentioned, I've checked that one before.

I gave a delay of 50 MS between writes and increased the buffer size in RAM to cache for longer recordings and lesser writes. This definitely seems to help, but the most I've written until now is about 72 MB.

[fwolter]

Did you find a sustainable solution? I have the same problem with PIC32 and a 4MB NOR flash in a logging application. After logging a few kilobytes of 13 byte chunks, the file system cannot be mounted anymore with the "Corrupted dir pair at {0x0, 0x1}" error.

[YKMorsy]

Did you find a sustainable solution? I have the same problem with PIC32 and a 4MB NOR flash in a logging application. After logging a few kilobytes of 13 byte chunks, the file system cannot be mounted anymore with the "Corrupted dir pair at {0x0, 0x1}" error.

Did you find a solution?