[Issue]: Issue #102 isn't fixed; not sure about its status

[jeffstearns]

Issue type

Bug

Summary

ESPConnect may fail to recognize a partition containing a littlefs filesystem, incorrectly reporting it as "Unused Flash".

Operating system

None

ESPConnect Session log (required)

This is a follow-on to issues #102 and #103. I'm unclear on the status of those tickets. They seem to be marked as closed, but I'm not sure whether the problems are believed to be fixed in release 1.15 or 1.16 or if a fix is planned for some future release.

To be specific: ESPConnect 1.15 and 1.16 preview treats some littlefs partitions as "Unused Flash" even though the partition contains a populated filesystem. The bug can be repeatably demonstrated using MicroPython 1.27.0 on an ESP32-C3.

I'm just posting this here to let you know that the bug exists in version 1.15 and 1.16 preview.

If it's still under development, feel free to close this ticket.
If it's believed to be fixed, I would be happy to do whatever I can to help.

v1.1.5 2026-01-13T02:41:49.496Z [ESPConnect-ui] Requesting serial port access...
v1.1.5 2026-01-13T02:41:52.637Z [ESPConnect-Debug] tasmota-webserial-esptool v(7.3.3)
v1.1.5 2026-01-13T02:41:52.638Z [ESPConnect-Debug] Serial input flushed before handshake.
v1.1.5 2026-01-13T02:41:52.638Z [ESPConnect-Debug] Opening serial port...
v1.1.5 2026-01-13T02:41:52.681Z [ESPConnect-Debug] Handshaking with ROM bootloader...
v7.3.3 webserial 2026-01-13T02:41:52.681Z  [ESPLoader]  USB-Serial: ESP32 Native USB (VID: 0x303a, PID: 0x1001)
v7.3.3 webserial 2026-01-13T02:41:52.681Z  [ESPLoader]  Max baudrate: 2000000
v7.3.3 webserial 2026-01-13T02:41:52.682Z  [ESPLoader]  Detected USB: VID=0x303a, PID=0x1001
v7.3.3 webserial 2026-01-13T02:41:52.682Z  [ESPLoader]  Trying USB-JTAG/Serial reset...
v7.3.3 webserial 2026-01-13T02:41:53.293Z  [ESPLoader]  Connected successfully with USB-JTAG/Serial reset.
v7.3.3 webserial 2026-01-13T02:41:53.315Z  [ESPLoader]  Chip type ESP32-C3
v1.1.5 2026-01-13T02:41:53.316Z [ESPConnect-Debug] Loading stub flasher...
v7.3.3 webserial 2026-01-13T02:41:53.318Z  [ESPLoader]  Uploading stub...
v7.3.3 webserial 2026-01-13T02:41:53.360Z  [ESPLoader]  Stub is now running...
v7.3.3 webserial 2026-01-13T02:41:53.360Z  [ESPLoader]  Detecting Flash Size
v7.3.3 webserial 2026-01-13T02:41:53.417Z  [ESPLoader]  FlashId: 0x164020
v7.3.3 webserial 2026-01-13T02:41:53.417Z  [ESPLoader]  Flash Manufacturer: 20
v7.3.3 webserial 2026-01-13T02:41:53.417Z  [ESPLoader]  Flash Device: 4016
v7.3.3 webserial 2026-01-13T02:41:53.417Z  [ESPLoader]  Auto-detected Flash size: 4MB
v7.3.3 webserial 2026-01-13T02:41:53.633Z  [ESPLoader]  Changed baud rate to 921600
v1.1.5 2026-01-13T02:41:53.634Z [ESPConnect-Debug] Getting security information...
v1.1.5 2026-01-13T02:41:53.637Z [ESPConnect-Debug] Handshake complete with ESP32-C3. Collecting device details...
v1.1.5 2026-01-13T02:41:53.705Z [ESPConnect-Debug] Chip detectFlashSize: 4MB
v1.1.5 2026-01-13T02:41:53.759Z [ESPConnect-Debug] Flash detect raw: getFlashSize=4MB, flashId=0x164020 (manuf=0x20, type=0x40, cap=0x16)
v7.3.3 webserial 2026-01-13T02:41:53.869Z  [ESPLoader]  Reading 1024 bytes from flash at address 0x8000...
v1.1.5 2026-01-13T02:41:53.876Z [ESPConnect-Debug] Loaded device details: ESP32-C3, 22 facts.
v1.1.5 2026-01-13T02:41:53.876Z [ESPConnect-ui] Connection established. Ready to flash.
v1.1.5 2026-01-13T02:41:53.876Z [ESPConnect-Debug] Connect flow finished (busy=false).

Checklist

• I searched for existing issues.
• I can reproduce this on the latest release.

[thelastoutpostworkshop]

ESPConnect reads the ESP-IDF partition table from the firmware/device. In the MicroPython v1.27.0 image you provided, the partition table only contains nvs, phy_init, and a factory app (1.9MB). There is no VFS/filesystem partition entry, so ESPConnect has nothing to display as a filesystem partition.

If MicroPython is creating a filesystem, it’s likely using “unused flash” by an internal convention rather than a declared partition. To make it visible/manageable in ESPConnect, the firmware needs a partition table that includes a vfs (LittleFS/FAT) entry.

Can you provide a binary image of a filesystem partition created with MicroPython v1.27.0 ?

[jeffstearns]

Happy to oblige. Here's the littlefs partition that I'm looking at right now. I'll also attach the partition table itself.

The most troubling thing about this bug is that MicroPython creates this littlefs filesystem by making a call into the ESP32 library. That call looks simple and clean. I don't recall any indication of trickery, so I'd expect that the ESP32 library should Do The Right Thing with respect to the partition table.

I can go track down that MicroPython filesystem creation code if you'd like. I recall that it was only a couple of lines.

manual_flash_region_0x200000_0x200000.bin.zip

Partition_Table_0x8000.bin.zip

[thelastoutpostworkshop]

@jeffstearns give me the full firmware .bin with the filesystem, so i can investigate it please

[jeffstearns]

Here is the application partition of the flash.

manual_flash_region_0x10000_0x1F0000.bin.zip

[thelastoutpostworkshop]

I wasn't clear enough, sorry, not a particular flash region, but the full .bin, it's the download flash backup in ESPConnect.
That way it will be easier for me to reproduce the issue.

[jeffstearns]

OK, here is the output of "DOWNLOAD FULL FLASH BACKUP".

used_flash_0x0.bin.zip

[thelastoutpostworkshop]

Thanks I will be able to test it.

[jeffstearns]

https://github.com/micropython/micropython/tree/master/ports/esp32#partition-table-and-filesystem-size has a very relevant discussion. It hints that it doesn't update the partition table when creating the filesystem. However, it doesn't say why.

Maybe they consider the partition table to be unnecessary, since the MicroPython application knows about the filesystem and "owns" the entire device.

Partition table and filesystem size
ESP32 firmware contains a bootloader, partition table and main application firmware, which are all stored in (external) SPI flash. The user filesystem is also stored in the same SPI flash. By default, MicroPython does not have a fixed entry in the ESP32 partition table for the filesystem. Instead it will automatically determine the size of the SPI flash upon boot, and then -- so long as there is no existing partition called "vfs" or "ffat" -- it will create a partition for the filesystem called "vfs" which takes all of the remaining flash between the end of the last defined partition up until the end of flash.

This means that firmware built for, say, a 4MiB flash will work on any device that has at least 4MiB flash. The user "vfs" filesystem will then take up as much space as possible.

This auto-detection behaviour can be overridden: if the ESP32 partition table does contain an entry called "vfs" or "ffat" then these are used for the user filesystem and no automatic "vfs" partition is added. This is useful in cases where only the MicroPython ESP32 application is flashed to the device (and not the bootloader or partition table), eg when deploying .uf2 files.

The file https://github.com/micropython/micropython/blob/master/ports/esp32/esp32_partition.c contains esp32_partition_make_new(), which updates the partition table. However, it appears that MicroPython doesn't call that function when it creates a filesystem during initial boot. In fact, I can't find any evidence that esp32_partition_make_new() is ever called anywhere. That smells like a MicroPython bug to me.

[jeffstearns]

I filed a bug report with the Micropython folks to see what they think. micropython/micropython#18681

[jeffstearns]

The MicroPython folks have responded to my bug report.

Bottom line: They think it's too risky for MicroPython to update the partition table when it creates the littlefs filesystem at runtime.

Paraphrasing their suggestion:

If the goal is for ESPConnect to detect MicroPython and the filesystem ,then you may need to actually read the contents of the factory partition and scan for occurrences of MicroPython (13x) or micropython/micropython.

if you find that, then you can scan the region of flash not listed in the partition table (not unused, but unspecified ) and detect the filesystem on it.

This is what MicroPython does at runtime, so it is certainly possible.