ESP32-C3 Error 19: filesystem error when connecting to Wifi network

[rorosaurus]

What happened?

ESP32-C3 build fails to save Wifi information and gets stuck loading (UM ☾) settings.

To Reproduce Bug

Board used: ESP32-C3 Super Mini
BIN used: WLEDMM_0.14.0-b28.34_esp32c3dev_4MB_M.bin

1. Manual OTA via WLED update page
2. Connect to WLED-AP, input wifi settings, save & connect

Expected Behavior

Expected: C3 will connect to wifi. Sound settings page should be visible on settings page

Actual: after wifi settings page timeouts, returns to color wheel main screen and red error message appears at bottom: "Error 19: A filesystem error has occured." Settings page is missing Temperature, 4LineDisplay, Rotary-Encoder, Autosave, AudioReactive, Animartrix (UM ☾) pages.

Install Method

From MoonModules Release Page

What version/release of MM WLED?

WLEDMM_0.14.0-b28.34_esp32c3dev_4MB_M.bin

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Happy to gather this, I just don't know how 😅 I thought there was an easy way to gather log from the web interface?

Anything else?

I've confirmed that my standard ESP32 dev board does not experiences these issues when OTA updating using WLEDMM_0.14.0-b28.34_esp32_4MB_M.bin.

Code of Conduct

• I agree to follow this project's Code of Conduct

[softhack007]

Hi,

File system error could appear when there is no partition table in flash, or when the partition table has a bad LittleFS entry (too big, or wrong type).

1. Manual OTA via WLED update page

How did you initially install your -C3 board?

this upload tool might work for you:
https://mm.kno.wled.ge/basics/install-wled-flasher/

As your board has "native usb" only, it might be necessary to manually bring the board into download mode:

• connect USB cable (to power the board)
• press "boot" button, hold the button pressed
• press "rst" button, release rst
• wait ~5 seconds, then release boot

Now you can use the flashing tool (see above) for uploading by USB cable.

[rorosaurus]

Initially installed latest release WLED via install.wled.me, then did the Manual OTA update. I've noticed some weird behavior with this process too, where sometimes the update would fail and sometimes it would succeed.

Tested USB upload with ESP-Flasher.exe, it uploaded successfully but it appears to be stuck in a boot loop. Confirmed on two otherwise known working ESP32-C3's. BIN used: WLEDMM_0.14.0-b28.34_esp32_4MB_M.bin

Using 'COM9' as serial port.
Connecting...
Detecting chip type... ESP32-C3
Connecting...

Chip Info:
 - Chip Family: ESP32
 - Chip Model: ESP32-C3 (revision 4)
 - Number of Cores: 1
 - Max CPU Frequency: 80MHz
 - Has Bluetooth: NO
 - Has Embedded Flash: NO
 - Has Factory-Calibrated ADC: NO
 - MAC Address: 40:4C:CA:F6:1D:20
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
 - Flash Size: 4MB
 - Flash Mode: qio
 - Flash Frequency: 80MHz
Erasing flash (this may take a while)...
Chip erase completed successfully in 14.8s
Flash will be erased from 0x00000000 to 0x00003fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x0018efff...
Flash params set to 0x002f
Compressed 12912 bytes to 9261...
Writing at 0x00000000... (100 %)
Wrote 12912 bytes (9261 compressed) at 0x00000000 in 0.3 seconds (effective 358.7 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 128...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (128 compressed) at 0x00008000 in 0.1 seconds (effective 414.5 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 592.0 kbit/s)...
Hash of data verified.
Compressed 1568432 bytes to 960002...
Writing at 0x00010000... (1 %)
Writing at 0x0001892c... (3 %)
...... (truncating for brevity)
Writing at 0x00184c6d... (98 %)
Writing at 0x0018b097... (100 %)
Wrote 1568432 bytes (960002 compressed) at 0x00010000 in 20.4 seconds (effective 616.1 kbit/s)...
Hash of data verified.

Leaving...
Hard Resetting...
Hard resetting via RTS pin...
Done! Flashing is complete!

Showing logs:
[17:11:07]ESP-ROM:esp32c3-api1-20210207
[17:11:07]Build:Feb  7 2021
[17:11:07]rst:0x7 (TG0WDT_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
[17:11:07]Saved PC:0x40049a42
[17:11:07]SPIWP:0xee
[17:11:07]mode:QIO, clock div:1
[17:11:07]load:0x3fcd6100,len:0x438
[17:11:07]ets_loader.c 78 
[17:11:09]ESP-ROM:esp32c3-api1-20210207
[17:11:09]Build:Feb  7 2021
[17:11:09]rst:0x7 (TG0WDT_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
[17:11:09]Saved PC:0x40049a42
[17:11:09]SPIWP:0xee
[17:11:09]mode:QIO, clock div:1
[17:11:09]load:0x3fcd6100,len:0x438
[17:11:09]ets_loader.c 78 
[17:11:10]ESP-ROM:esp32c3-api1-20210207
[17:11:10]Build:Feb  7 2021
[17:11:10]rst:0x7 (TG0WDT_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
[17:11:10]Saved PC:0x40049a42
[17:11:10]SPIWP:0xee
[17:11:10]mode:QIO, clock div:1
[17:11:10]load:0x3fcd6100,len:0x438
[17:11:10]ets_loader.c 78 

WLEDMM_0.14.0-b27.31_esp32c3dev_4MB_M.bin also has the same issue. I checked a few releases back until MoonModules v0.14.0-b15 before giving up, and they all appear to get stuck in a boot loop after flashing.

The chip markings read ESP32-C3, but I think the actual SoC is ESP32-C3FH4 because there is no external flash. Yet esptool in the ESP-Flasher appears to report "No embedded flash"? Perhaps that is related?

Would anyone be able to confirm if flashing these BINs work for you? Does your dev board have external flash?

Thanks all! 🙏

[softhack007]

[17:11:10]rst:0x7 (TG0WDT_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
[17:11:10]Saved PC:0x40049a42
[17:11:10]SPIWP:0xee
[17:11:10]mode:QIO, clock div:1
[17:11:10]load:0x3fcd6100,len:0x438
[17:11:10]ets_loader.c 78

I've googled this message, and it seems that on some -C3 boards, the second stage bootloader fails to start. It looks like building the firmware with flash mode "dio" (dual i/o) instead of "qio" (quad i/o) helps.

• Boot loop on ESP32-C3 platformio/platform-espressif32#622

I can confirm that the release firmware basicially works, I've tested it on a "real devkit" -c3-devkitM1 (however not based on -mini soc) that I have at hand.

-C3 (and -S2, -S3) are still experimental in WLED, and some boards work while others simply refuse to cooperate 🤷

Your best chance is actually to build AND upload the firmware from the development environment (VSCode+platformIO).

Select env:esp32c3dev_4MB_M as build environment, but change the qio inboard_build.flash_mode = qio to dio

WLED/platformio.ini

Lines 1916 to 1924 in 35032df

	;; MM environment for generic ESP32-C3 -> 4MB flash, no PSRAM
	[env:esp32c3dev_4MB_M]
	extends = esp32_4MB_V4_S_base
	;board_build.flash_mode = dout
	platform = ${esp32.platformV4}
	platform_packages = ${esp32.platformV4_packages}
	board_build.flash_mode = qio
	board = esp32-c3-devkitm-1
	;board_build.partitions = tools/WLED_ESP32_4MB_256KB_FS.csv ;; 1.8MB firmware, 256KB filesystem (esptool erase_flash needed when changing from "standard WLED" partitions)

The KB has some guidance for using VSCode+platformIO:

• https://kno.wled.ge/advanced/compiling-wled/
• (Doc request) compiling in platformio - selecting build envs via dropdown Aircoookie/WLED-Docs#161

[mitch030504]

[17:11:10]rst:0x7 (TG0WDT_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
[17:11:10]Saved PC:0x40049a42
[17:11:10]SPIWP:0xee
[17:11:10]mode:QIO, clock div:1
[17:11:10]load:0x3fcd6100,len:0x438
[17:11:10]ets_loader.c 78

I've googled this message, and it seems that on some -C3 boards, the second stage bootloader fails to start. It looks like building the firmware with flash mode "dio" (dual i/o) instead of "qio" (quad i/o) helps.

• Boot loop on ESP32-C3 platformio/platform-espressif32#622

I can confirm that the release firmware basicially works, I've tested it on a "real devkit" -c3-devkitM1 (however not based on -mini soc) that I have at hand.

-C3 (and -S2, -S3) are still experimental in WLED, and some boards work while others simply refuse to cooperate 🤷

Your best chance is actually to build AND upload the firmware from the development environment (VSCode+platformIO).

Select env:esp32c3dev_4MB_M as build environment, but change the qio inboard_build.flash_mode = qio to dio

WLED/platformio.ini

Lines 1916 to 1924 in 35032df

	;; MM environment for generic ESP32-C3 -> 4MB flash, no PSRAM
	[env:esp32c3dev_4MB_M]
	extends = esp32_4MB_V4_S_base
	;board_build.flash_mode = dout
	platform = ${esp32.platformV4}
	platform_packages = ${esp32.platformV4_packages}
	board_build.flash_mode = qio
	board = esp32-c3-devkitm-1
	;board_build.partitions = tools/WLED_ESP32_4MB_256KB_FS.csv ;; 1.8MB firmware, 256KB filesystem (esptool erase_flash needed when changing from "standard WLED" partitions)

The KB has some guidance for using VSCode+platformIO:

• https://kno.wled.ge/advanced/compiling-wled/
• (feature request) compiling in platformio - selecting build envs via dropdown Aircoookie/WLED-Docs#161

this worked for me, here is the current firmware for any1 else that has this(or a similar) issue
WLEDMM_0.14.0-b28.34_esp32c3dev_4MB_M.zip

[rorosaurus]

Thank you @softhack007 for the info and advice! Thanks @mitch030504 that BIN appears to boot correctly for me!

Though I did notice LittleFS failed to mount in the logs. I was able to connect to it via the web interface and save Wifi info, though. Attaching in case that's not normal:

...
Done! Flashing is complete!

Showing logs:
[15:23:38]E (299) esp_core_dump_flash: No core dump partition found!
[15:23:38]E (299) esp_core_dump_flash: No core dump partition found!
[15:23:39]./components/esp_littlefs/src/littlefs/lfs.c:1229:error: Corrupted dir pair at {0x0, 0x1}
[15:23:39]E (449) esp_littlefs: mount failed,  (-84)
[15:23:39]E (449) esp_littlefs: Failed to initialize LittleFS
[15:23:42]E (4296) I2S: i2s_driver_uninstall(2047): I2S port 0 has not installed

Though I do want to note a couple things:

1. Updating OTA, I don't encounter the boot loop issue, just the writing to filesystem issues (web interface loaded fine)

2. My board isn't exactly a -mini type with the typical shield cover. It's a bare 5x5mm SoC. Perhaps there's no difference but I wanted to be clear in case there are multiple cases to consider here and these issues aren't dupes.