QUERY · ISSUE

ESP32S3 4M Port missing. Partition table in Firmware in file is wrong

openby mispacekopened 2025-06-26updated 2025-06-26

bugport-esp32

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

CANDIDATE · PULL REQUEST

esp32: auto-detect the SPI flash size and automatically size the filesystem

mergedby dpgeorgeopened 2025-05-22updated 2025-06-13

port-esp32

Summary

Currently in the esp32 port the size of the SPI flash must be configured at build time, eg 4MiB, 8MiB, etc. Also, the esp32 partition table must be configured at build time, which depends on the size of the SPI flash. A bigger flash means more can be allocated to the user filesystem.

This PR makes it so the SPI flash size is automatically determined at runtime, and the filesystem size is automatically set to take up as much room as possible.

This works by:

Setting the SPI flash size to be 4MiB in the build (or some other value, as long as the firmware app fits).
Removing the vfs partition from the esp32 partition table (only nvs, phy_init and firmware remains in the partition table).
At boot, query the physical size of the SPI flash and use that as the actual size in the code.
If it doesn't already exist, automatically create a vfs partition which takes up the flash from the end of the firmware partition to the end of flash.

This allows simplifying a lot of board configurations, and removing some board variants that just change the flash size.

It's also fully backwards compatible, in the following sense:

Existing boards with MicroPython firmware will continue to work with the same filesystem, ie the filesystem won't be erased when the firmware is updated.
If a user has a custom esp32 partition table and installs MicroPython as a bare app into the app partition, the new MicroPython firmware will honor the esp32 partition table and use either vfs or ffat partitions as the filesystem.

Eventually this mechanism will be extended:

to other ports, probably rp2 next
to allow users to customise the filesystem layout, and enable ROMFS partition(s) without rebuilding firmware

Testing

Tested with ESP32_GENERIC on a board with 4MiB of flash, and ESP32_GENERIC_S2 on a board with 16MiB flash. The filesystem size was correctly detected.

Trade-offs and Alternatives

~~Boards configured for OTA have not been changed, they still define the filesystem partition explicitly.~~ PR updated to now cover all boards.
It may be that the physical flash size cannot be detected correctly, but I think the IDF has covered most cases by now.
Custom board definitions can override the auto detect feature by defining their own MICROPY_BOARD_STARTUP macro.