Formatting littlefs fails on esp32s2 boards

[mp-se]

When trying to format / mount LittleFS on an esp32s2 board this fails. It works when using Spiffs. See the repo on the link. Issue has been confirmed both on the s2 dev and s2 mini boards. Works fine on the standard esp32 dev kit.

https://github.com/mp-se/wokwi-fs

Example of the log output:

entry 0x4004c18c [ 674][D][esp32-hal-tinyusb.c:680] tinyusb_enable_interface(): Interface CDC enabled [ 677][D][esp32-hal-tinyusb.c:569] tinyusb_load_enabled_interfaces(): Load Done: if_num: 2, descr_len: 75, if_mask: 0x10 E (1266) esp_littlefs: ./components/esp_littlefs/src/littlefs/lfs.c:1225:error: Corrupted dir pair at {0x0, 0x1} E (1266) esp_littlefs: mount failed, (-84) E (1269) esp_littlefs: Failed to initialize LittleFS [ 702][E][esp32-hal-misc.c:128] disableCore0WDT(): Failed to remove Core 0 IDLE task from WDT E (1299) esp_littlefs: Failed to format filesystem [ 727][E][LittleFS.cpp:120] format(): Formatting LittleFS failed! Error: -1 [ 728][E][LittleFS.cpp:95] begin(): Mounting LittleFS failed! Error: -1 [ 734][E][vfs_api.cpp:24] open(): File system is not mounted

[mp-se]

This is the code for the LittleFS.format() function. From the log output it looks like it fails in the first function. The code is identical in the SPIFFS implementation.

bool LittleFSFS::format() { disableCore0WDT(); esp_err_t err = esp_littlefsformat(partitionLabel); enableCore0WDT(); if(err){ log_e("Formatting LittleFS failed! Error: %d", err); return false; } return true; }

[mp-se]

I did another experiment and added a formatted littlefs.bin to the merged image.

Using that approach I can read a file that I embedded but not write to the partition. Could the issue be that the partition becomes mounted as read only or is marked as ROM ?

[urish]

Using that approach I can read a file that I embedded but not write to the partition. Could the issue be that the partition becomes mounted as read only or is marked as ROM ?

It's the same partition that works in read-write mode for SPIFFS, right?

[mp-se]

I havent tested the last step with spiffs but can do that later

[mp-se]

I can confirm that running the same with the SPIFFS API works fine. I'm using the latest arduino fwk from platformio form my tests, are there any other components in the simulator that can have an impact on this ?

[urish]

I spent a few hours debugging it, and figured out that lfs_dir_commitcrc fails with LFS_ERR_CORRUPT error.

[urish]

Another update: seems like there is some data corruption happening when writing a block to the SPI Flash on the ESP32-S2.

This is what the code running inside the simulation is trying to write:

#6  0x4002e7a4 in spi_flash_chip_generic_write (chip=0x3ffc02f4 <default_chip>,
    buffer=0x3ffcdf18, address=<optimized out>, length=<optimized out>)
    at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/spi_flash/spi_flash_chip_generic.c:289
289     /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/spi_flash/spi_flash_chip_generic.c: No such file or directory.
(gdb) x/64ub buffer
0x3ffcdf18:     1       0       0       0       240     15      255     247
0x3ffcdf20:     108     105     116     116     108     101     102     115
0x3ffcdf28:     47      224     0       16      0       0       2       0
0x3ffcdf30:     0       16      0       0       96      0       0       0
0x3ffcdf38:     255     0       0       0       255     255     255     127
0x3ffcdf40:     254     3       0       0       112     31      252     72
0x3ffcdf48:     82      167     93      209     255     255     255     255
0x3ffcdf50:     255     255     255     255     255     255     255     255

But this is the data that ends up in the virtual SPI Flash after the writes finishes:

0x390000:   1,   0,   0,   0,   144, 10,  153, 132,
0x390008:   108, 105, 116, 116, 255, 255, 255, 255, 
0x390010:   47,  224, 0,   16,  0,   0,   2,   0,
0x390018:   0,   16,  0,   0,   96,  0,   0,   0,
0x390020:   255, 0,   0,   0,   255, 255, 255, 127, 
0x390028:   254, 3,   0,   0,   112, 31,  252, 72,
0x390030:   82,  167, 93,  209, 255, 255, 255, 255,
0x390038:   255, 255, 255, 255, 255, 255, 255, 255,

Bytes 4, 5, 6 and 7 are different!

[urish]

And also bytes 12, 13, 14, and 15. Some progress :)

[urish]

Fix is up - can you please test again and report?

[mp-se]

The simple test project works fine but I need to do some more tests with my bigger project to confirm.

[mp-se]

I can confirm that the problem is solved. Thanks for fixing this so fast.