The latest firmware littlefs is faulty

[XYartlab]

I found a bug, and I recently compiled the firmware for the RP2040 driver version:260324.
I defined: #define WEBUI_ENABLE 3; #define WEBUI_INFLASH 1; #define SDCARD_ENABLE 2.
However, LittleFS is not behaving normally. After powering on, if the first connected is the webui and only the webui is connected, then the webui can access ESP3D webui3.0 normally (essentially, LittleFS can access normally), the $F command does not report an error, and everything is fine. While the webui is running normally, if a USB or TCP 23 connection is added, the sender's $F command will report an error "LittleFS mount failed!" and the webui will enter the file upload page with an error (Error: board does not answered properly 500). If powered on directly with a USB or TCP connection, $F will report an error "LittleFS mount failed!" and the webui will open the file upload page with an error "Error: board does not answered properly 500".
In version 260122, everything was normal.

[XYartlab]

[terjeio]

This may due to corrupted littlefs data, erasing the flash and reflasing may help. Or it could be due to issues with the SD card? If you unmount that do you still get the error?
Note that the question marks in the file names may indicate that they contain non-ascii characters, grblHAL does not support non-ascii characters.

FYI in the next build I will expand the $FF command to allow reformatting the littlefs partition.

[XYartlab]

I tried erasing the flash, but the symptoms persist. If the SD card is not inserted, $F reports an error: error:65 - File system not mounted. However, littlefs still cannot be accessed, and the webui will enter the file upload page with an error (Error: board does not answered properly 500). It seems there is an issue with the mounting of littlefs in this firmware.
Ideally, $F should list the littlefs directory (whether or not the SD card is inserted), and the webui should always be able to access it.

[XYartlab]

This may due to corrupted littlefs data, erasing the flash and reflasing may help. Or it could be due to issues with the SD card? If you unmount that do you still get the error? Note that the question marks in the file names may indicate that they contain non-ascii characters, grblHAL does not support non-ascii characters.

FYI in the next build I will expand the $FF command to allow reformatting the littlefs partition.

I compiled the latest firmware you submitted, and now littlefs doesn't report any errors. The $F command works normally, and the web UI is accessible. However, this commit seems to have removed the display of FS:FatFS/littlefs capacity information in $I.

[XYartlab]

With the latest firmware, loading the WebUI page is surprisingly slow, taking over 20 seconds. Previous versions loaded within 5 seconds. Once the page is loaded, the response speed is basically normal. I am using an RP2040+W5100S.

[XYartlab]

With the latest firmware, loading the WebUI page is surprisingly slow, taking over 20 seconds. Previous versions loaded within 5 seconds. Once the page is loaded, the response speed is basically normal. I am using an RP2040+W5100S.

I used the 250MHz overclock setting again, and it returned to loading the webui within 2-6 seconds most of the time. When I used 200MHz, I could adjust the W5100S SPI frequency (e.g., increasing to 40MHz) and the SD SPI frequency (e.g., 18MHz), but when using 250MHz, adjusting the frequency would cause the SD to work abnormally.
In the 260124 firmware, using 250MHz + SD 18MHz worked basically normally (loading files and running for over an hour). With today's firmware, it seems the SD frequency cannot be adjusted much. Of course, simple practical testing revealed that increasing the SPI frequency has minimal impact on file upload speed improvement.

[terjeio]

However, this commit seems to have removed the display of FS:FatFS/littlefs capacity information in $I.

I moved it to a new command, $FI, due to reading the data off the SD card took a long time on the RP2040 causing timeout on $I in ioSender.

I used the 250MHz overclock setting again, and it returned to loading the webui within 2-6 seconds most of the time.

For me loading the WebUI takes less than a second, what takes time is reading the file listing off the SD card. Reloading the WebUI, including the file listing, takes less than a second. Compared to other drivers RP2040 has slow SD access, I do not know why.

Ideally, $F should list the littlefs directory (whether or not the SD card is inserted), and the webui should always be able to access it.

I'll add this in the next commit. Note that files uploaded to littlefs via the WebUI maintenance page are flagged as hidden and will not be shown in other file listings.