Skip to content

ESP32: Significant size increase with MICROPY_ROM_TEXT_COMPRESSION and external modules #17593

@ricksorensen

Description

@ricksorensen

Port, board and/or hardware

XIAO Esp32S3 using ESP32_GENERIC_S3 board

MicroPython version

Pull with 1.26 preview[1b0cdc0] 202507011430 UTC wih added ulab or st7789_mpy USER_C_MODULES[1b0cdc0]

MicroPython v1.26.0-preview.290.g1b0cdc079.dirty on 2025-07-01; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3

Reproduction

# idf version 5.4.1
# ubuntu 24.04
$ make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT USER_C_MODULES=/tmp/upwork/myesp32mods/ulab/code/micropython.cmake
$ stat --format=%s "build-ESP32_GENERIC_S3-SPIRAM_OCT/micropython.bin"

Expected behaviour

Good build with a micropython.bin size of about 1883584 bytes for ulab build based on 1.25

Observed behaviour

Error: app partition is too small for binary micropython.bin size 0x307ed0:
  - Part 'factory' 0/0 @ 0x10000 size 0x1f0000 (overflow 0x117ed0)
...

micropython.bin` size = 3178192 bytes

Additional Information

Not sure if this is a bug or a procedure problem on my part-

I built versions using ESP-IDF v5.4.1 with MICROPY_ROM_TEXT_COMPRESSION ON and OFF for both ulab and the st7789_mpyh modules. I turned the compression off using an edited esp32_common.cmake file:

$git diff 
diff --git a/ports/esp32/esp32_common.cmake b/ports/esp32/esp32_common.cmake
index 09b120391..29da7ab2a 100644
--- a/ports/esp32/esp32_common.cmake
+++ b/ports/esp32/esp32_common.cmake
@@ -30,7 +30,8 @@ endif()
 # Enable error text compression by default.
 if(NOT MICROPY_ROM_TEXT_COMPRESSION)
-    set(MICROPY_ROM_TEXT_COMPRESSION ON)
+    message(STATUS "set TEXT_COMPRESSION OFF")
+    set(MICROPY_ROM_TEXT_COMPRESSION OFF)
 endif()

The binary size results are:

Ext Module Comp on Comp off
ulab 3178192 1883584
st7789_mpy 1788928 1684688

See discusstion #17479 and older #17225 for more details. It is not the size itself, but the significant increase with compression on , which should shrink size I believe.

This seems to impact ESP32 based boards only, but does impact similarly both C3 and S3 builds. The same behavior is seen with IDF 5.2.2

My full test script is

idf.py --version
pwd
git status -uno
make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT submodules 2>&1 > mksubmod

make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT USER_C_MODULES=/tmp/upwork/myesp32mods/ulab/code/micropython.cmake 2>&1 > mkcompon
stat --format=%s "build-ESP32_GENERIC_S3-SPIRAM_OCT/micropython.bin"
tar czf S3compon.ulab.tgz mkcompon build-ESP32_GENERIC_S3-SPIRAM_OCT > /dev/null
rm -fr build-ESP32_GENERIC_S3-SPIRAM_OCT
cp -p esp32_common.compoff.cmake esp32_common.cmake
git status -uno
git diff esp32_common.cmake
make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT USER_C_MODULES=/tmp/upwork/myesp32mods/ulab/code/micropython.cmake 2>&1 > mkcompoff
stat --format=%s "build-ESP32_GENERIC_S3-SPIRAM_OCT/micropython.bin"
tar czf S3compoff.ulab.tgz mkcompoff build-ESP32_GENERIC_S3-SPIRAM_OCT > /dev/null
rm -fr build-ESP32_GENERIC_S3-SPIRAM_OCT
git restore esp32_common.cmake

git status -uno
make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT USER_C_MODULES=/tmp/upwork/myesp32mods/st7789_mpy/micropython.cmake 2>&1 > mkcompon
stat --format=%s "build-ESP32_GENERIC_S3-SPIRAM_OCT/micropython.bin"
tar czf S3compon.st7789.tgz mkcompon build-ESP32_GENERIC_S3-SPIRAM_OCT > /dev/null
rm -fr build-ESP32_GENERIC_S3-SPIRAM_OCT
cp -p esp32_common.compoff.cmake esp32_common.cmake
git status -uno
git diff esp32_common.cmake
make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT USER_C_MODULES=/tmp/upwork/myesp32mods/st7789_mpy/micropython.cmake 2>&1 > mkcompoff
stat --format=%s "build-ESP32_GENERIC_S3-SPIRAM_OCT/micropython.bin"
tar czf S3compoff.st7789.tgz mkcompoff build-ESP32_GENERIC_S3-SPIRAM_OCT > /dev/null
rm -fr build-ESP32_GENERIC_S3-SPIRAM_OCT
git restore esp32_common.cmake

Code of Conduct

Yes, I agree

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      pFad - Phonifier reborn

      Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

      Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


      Alternative Proxies:

      Alternative Proxy

      pFad Proxy

      pFad v3 Proxy

      pFad v4 Proxy