File Write and Close or Unlink gives -22 error code

[BenjamimKrug]

When I perform many file writes, like 300 or so(the amount seems to be random), it stops being able to write the files and once I close it, I get a return code -22, which means invalid arguments. I get the same error code when I call an fs_unlink function, so in essence I have the Flash bricked as long as this error occurs. All flash operations takes many seconds, when I was writing about 12 bytes it took 14s, now I'm writing 120 bytes and it takes 120s more or less. The weird part is that after good while, previously it was 1h, but now it seems like 3 hours(could be a number of writes and now it takes longer since the writes take longer) it just starts working again like it was nothing. An important info is that the flash is not filled, it has 2MB, and 300 120 bytes files only gives 36000 bytes. I have already posted about this issue on the nordic devzone forum about it on (https://devzone.nordicsemi.com/f/nordic-q-a/97005/file-delete-in-littlefs-results-in--22-error).

Expected behavior I expected to write, close and unlink files without getting any error codes.

Impact It completly ruins the device, as I'll lose a lot of data during the 3 hours it doesn't function, and pretty much stops our project

Logs and console output

Using a logic analyser I got some readings of the SPI, but they weren't very precise and muy analyser isn't very good so I can't get good readings as it times out frequently.

The prints that are "something:" -22 are my process to track down the function originating the -22 error code (I had to do it manually as VScode is not cooperating in navigating through the files), in the end I got down this track: fs_unlink() lfs_dir_commit() lfs_orphaningcommit() lfs_dir_relocatingcommit() lfs_dir_splittingcompact() lfs_dir_split() lfs_dir_alloc() lfs_bd_read() lfs->cfg->read()

I couldn't find the function after that point, as it gets to the api struct and I don't know what it calls.

Enviroment -OS: Windows 11 -NRF Connect SDK v2.3.0 and v2.2.0, happens on both -nRF52832 as the processor -mx25r1635f as the external flash -littleFS on the the external flash -The problem happened on the 6 boards tested up to now

[de-nordic]

Will take a look.

[nordicjm]

Can you try setting file system log level to debug and see if there's any messages around the time it stops working?

[Laczen]

@BenjamimKrug there are quite some limitations in using littlefs. IIRC each file requires a complete eraseblock for storage, as your device only has 512 blocks (and maybe not everything is available for littlefs) you will be reaching this limit very easily. I think there are several of these problems reported on the littlefs github.

[Laczen]

BTW, is #54779 still open ?

[BenjamimKrug]

@Laczen, yes #54779 is still open, and if you are correct about reaching the max number of files due to the number of blocks available, that problem would be the one I'd have to fix. @nordicjm I'll set the debug level and send it here.

[Laczen]

@Laczen, yes #54779 is still open, and if you are correct about reaching the max number of files due to the number of blocks available, that problem would be the one I'd have to fix. @nordicjm I'll set the debug level and send it here.

You are probably having the same issue, but now reading on a out of range address. You will need to provide full setup details (dts, ...) as it was impossible to reproduce #54779.

[BenjamimKrug]

I'd have to send you the files privately as the code is from the company I work at, so I can't post it here.

[Laczen]

@BenjamimKrug, while going over #54779 again I noticed that your device is a 16Mb device but you are declaring a partition of 16MB, you need to reduce the storage partition:

lfs1_part: partition@0 {
            label = "storage";
            reg = <0x00000000 0x1000000>;
        };

needs to be:

lfs1_part: partition@0 {
            label = "storage";
            reg = <0x00000000 0x200000>;
        };

The startup debugging for the littlelfs setup is crucial: always report the result of the mount: shows that there is something wrong with the setup, your device does not have 4096 blocks of 4096 bytes.

[BenjamimKrug]

@Laczen, I made the change you said to and now I can write files normally, not being limited to 120 bytes, fixing #54779. I'll have to rework the firmware now to write everything on one file and test a bit more, but theoretically, both the issues are now fixed.

[Laczen]

I hope you understand why it is important to share details about your setup.