ESP32S3 4M Port missing. Partition table in Firmware in file is wrong
Port, board and/or hardware
esp32
MicroPython version
I have a problem on 4M variant of ESP32S3 (ESP32S3 Super Mini)
4M variant of firmware working good, without any problems.
But 4M firmware download is missing now on Micropython firmware download page.
I try to flash "universal" firmware v1.25.0 (2025-04-15)
and now my Filesystem not working.
MPY: soft reboot
Traceback (most recent call last):
File "_boot.py", line 11, in <module>
File "inisetup.py", line 38, in setup
File "inisetup.py", line 7, in check_bootsec
OSError: (-24579, 'ESP_ERR_FLASH_NOT_INITIALISED')
MicroPython v1.25.0 on 2025-04-15; Generic ESP32S3 module with ESP32S3
I try to compare 4M firmware and new firmware, and partition table at adress 0x8000 in flash memory is different.
Partition table in new firmware is for 6MB filesystem.
Please bring back the 4M variant of Micropython
Reproduction
Download new image from Micropython website for ESP32S3
https://micropython.org/resources/firmware/ESP32_GENERIC_S3-20250415-v1.25.0.bin
Upload it to 4M variant of ESP32S3 and open REPL
Expected behaviour
I expected working filesystem, but vfs partition is broken now.
Observed behaviour
Flashing back to 4M Variant firmware helps... but for other people 4M build is missing now on download page
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
Micropython fails to update the partition table when it creates a flash filesystem at boot
Port, board and/or hardware
MicroPython v1.27.0 on 2025-12-09; ESP32C3 module with ESP32C3 (ESP-ROM:esp32c3-api1-20210207 Build:Feb 7 2021)
MicroPython version
MicroPython v1.27.0 on 2025-12-09; ESP32C3 module with ESP32C3
Reproduction
- Erase flash
- Install MicroPython v1.27.0
- Boot the device into the Micropython REPL
- At this point, Micropython has created a littlefs filesystem in the unused flash space.
- Disconnect the device.
- Connect the device to https://thelastoutpostworkshop.github.io/ESPConnect/ or similar so you can inspect the flash partitions.
- Download the partition table and "unused" partitions. Inspect them with a binary editor.
- Note that the "unused" partition actually contains a littlefs filesystem, but that filesystem is not listed in the partition table. This is a bug.
Expected behaviour
The formerly unused flash partition should be listed in the partition table as containing a littlefs filesystem.
Observed behaviour
The partition table does not include the littlefs filesystem.
Additional Information
Maybe you consider the partition table to be unnecessary, since the MicroPython application knows about the filesystem and "owns" the entire device. But that seems risky to folks who use low-level tools to debug devices.
https://github.com/micropython/micropython/tree/master/ports/esp32#partition-table-and-filesystem-size has a relevant comment. It hints that it doesn't update the partition table when creating the filesystem. However, it doesn't say why:
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.
Code of Conduct
Yes, I agree