mikee47
commented
5 years ago @kmihaylov You've highlighted the problem very accurately! The logic in spiffs_mount_internal() (spiffs_sming.c line 114) is too simplistic -
uint32_t dat;
bool writeFirst = false;
flashmem_read(&dat, cfg->phys_addr, 4);
//debugf("%X", dat);
if (dat == UINT32_MAX)
{
debugf("First init file system");
spiffs_format_internal(cfg);
writeFirst = true;
}The volume gets wiped if SPIFFS sector #0 is in the erased state when the device reboots, which is a perfectly legitimate state for SPIFFS to be in.
Here's a better way:
// Call SPIFFS_mount() with appropriate parameters
int res = do_mount();
// Check result
if(res < 0) {
// Mount failed, format the volume then retry
format();
res = do_mount();
}
// Final result of mount operation
return res;There's also a volume checking function in SPIFFS, which is time-consuming but could be integrated like this:
int res = do_mount();
if(res < 0) {
// Mount failed, perform a volume check
check_fs();
res = do_mount();
if(res < 0) {
format();
res = do_mount();
}
}
return res; // Final result of mount operationYou can find some example code for the above here
kmihaylov
slaff
Hello. Finally I found when my FS is crashing. It is some time after data has been written to it, that's why it was a little bit hard to figure it out when exactly the bug appears.
I found that while there is no need for api_spiffs_erase, the consistency of the FS is OK, the device can be rebooted w/o problems (data loss, broken FS).
On the first appearance of "api_spiffs_erase", however, the FS is immediately broken.
I made a simple program where one can write some data to the FS. Issue command
save 10where the integer is how many times the fileSetContent will be called. The sample text is in the cpp file and can be changed. I set it to 10 bytes for convenience (idk how SPIFFS reserves bytes for the filename and etc.).You have to try with some random repetition values, 100 is good to begin with. When you figure out where "api_spiffs_erase" is shown you can decrease the argument of
saveto this position -1.I got "api_spiffs_erase" on the 63rd write (630 bytes of data excluding what bytes were reserved for file name, spiffs, etc).
If I try to repeat the file save 62 times, the FS works OK, the device can be safely rebooted w/o data loss. After the reboot only one
saveoperation is needed to reach "api_spiffs_erase" and the FS gets immediately broken. On the next reboot it is formatted by the firmware.Example code is provided here: https://github.com/kmihaylov/Sming_fsTest.git
Tested with commit 5300c0b (current develop)