image_too_big error when using espflash v3.0.0

[armandas]

I tried to upgrade to v3.0.0, but it produces the following error:

[2024-03-20T08:04:58Z INFO ] Serial port: '/dev/ttyACM0'
[2024-03-20T08:04:58Z INFO ] Connecting...
[2024-03-20T08:04:58Z INFO ] Using flash stub
Chip type:         esp32s3 (revision v0.2)
Crystal frequency: 40 MHz
Flash size:        8MB
Features:          WiFi, BLE
MAC address:       48:27:e2:82:7d:58
Error: espflash::image_too_big (link)

  × Supplied ELF image of 1114592B is too big, and doesn't fit configured app partition of 1048576B
  help: Reduce the size of the binary or increase the size of the app partition.

V2.1.0 works fine:

[2024-03-20T07:58:18Z INFO ] 🚀 A new version of espflash is available: v3.0.0
[2024-03-20T07:58:18Z INFO ] Serial port: '/dev/ttyACM0'
[2024-03-20T07:58:18Z INFO ] Connecting...
[2024-03-20T07:58:18Z INFO ] Using flash stub
Chip type:         esp32s3 (revision v0.2)
Crystal frequency: 40MHz
Flash size:        8MB
Features:          WiFi, BLE
MAC address:       48:27:e2:82:7d:58
App/part. size:    1,114,592/8,323,072 bytes, 13.39%
[00:00:00] [========================================]      14/14      0x0                                                                                                                                                                    [00:00:00] [========================================]       1/1       0x8000                                                                                                                                                                 [00:00:08] [========================================]     650/650     0x10000                                                                                                                                                                [2024-03-20T07:58:28Z INFO ] Flashing has completed!

[SergioGasquez]

Hi! Mind giving some more details? Are you using espflash or cargo-espflash? Is it a std or no_std app? Also, mind trying using --no-stub and --flash-size arguments?

[armandas]

Sure. I am using the espflash command, as described here. My project is using std, but how does that affect the flashing tool?

--no-stub didn't help, but it did work with --flash-size 8mb. From the output in my previous post, however, we can see that the tool already knows there's 8MB of flash.

[armandas]

Also just want to add that I haven't explicitly configured the partitions, but V2 tool had no problem with it, so from usability perspective, the new tool should not break either.

[empirephoenix]

Hi, I'm running into the same issue since the last update of espflash

× Supplied ELF image of 1582768B is too big, and doesn't fit configured app partition of 1048576B
  help: Reduce the size of the binary or increase the size of the app partition.

My goal is to convert the binary, so I can use it OTA as before.
If I understand correctly, --merged is not correct for my use case, as it will contain the whole flash, not just the new image for the ota partition, but without merged, I cannot use --partition-table. I tried settings --flash-size, but it did not have any apparent change.

My actual partition table is:

nvs,      data, nvs,     ,        16k,
otadata,  data, ota,     ,        8k,
phy_init, data, phy,     ,        4k,
ota_0,    app,  ota_0,   ,        1792K,
ota_1,    app,  ota_1,   ,        1792K,
storage,  data, spiffs,  ,        400K, 

Failed command
cargo espflash save-image --chip esp32 image.bin

Workaround

cargo install espflash --version 2.1.0 cargo-espflash
cargo install espflash --version 2.1.0 espflash

After this the same command returns:

[2024-04-02T09:31:18Z INFO ] 🚀 A new version of cargo-espflash is available: v3.0.0
   Compiling plant-ctrl2 v0.1.0 (/home/empire/workspace/PlantCtrl/rust)
    Finished dev [optimized + debuginfo] target(s) in 7.33s
Chip type:         esp32
Merge:             false
Skip padding:      false
App/part. size:    1,582,768/4,128,768 bytes, 38.34%

[SergioGasquez]

Hi! Can any of the affected users try to reproduce this issue with the current main: cargo install espflash --git https://github.com/esp-rs/espflash or cargo install cargo-espflash --git https://github.com/esp-rs/espflash??

Thanks in advance!

[jessebraham]

It would also be helpful if somebody could provide a project which reliably triggers this error when trying to flash.

[armandas]

Hi! Can any of the affected users try to reproduce this issue with the current main: cargo install espflash --git https://github.com/esp-rs/espflash or cargo install cargo-espflash --git https://github.com/esp-rs/espflash??

Thanks in advance!

The issue persists.

espflash --version
espflash 4.0.0-dev

espflash flash target/xtensa-esp32s3-espidf/debug/test-espflash                                                                                                        2.1m  Tue 25 Feb 2025 20:39:35 JST
[2025-02-25T11:40:21Z INFO ] Serial port: '/dev/ttyACM0'
[2025-02-25T11:40:21Z INFO ] Connecting...
[2025-02-25T11:40:21Z INFO ] Using flash stub
Chip type:         esp32s3 (revision v0.2)
Crystal frequency: 40 MHz
Flash size:        8MB
Features:          WiFi, BLE
MAC address:       48:27:e2:82:7d:58
Error: espflash::image_too_big (link)

  × Supplied ELF image of 1061968B is too big, and doesn't fit configured app partition of 1048576B
  help: Reduce the size of the binary or increase the size of the app partition.

It would also be helpful if somebody could provide a project which reliably triggers this error when trying to flash.

What I just noticed is that the issue can be easily reproduced if the binary is larger than ~1 MB. So I created an empty project and comment out the optimization flag in Cargo.toml:

[profile.dev]
debug = true    # Symbols are nice and they don't increase the size on Flash
# opt-level = "z"

[jessebraham]

Okay, for some reason we have the default factory partition size for the ESP32-S3 set to 1MB, while many other chips use 4MB instead. Don't recall where we even got these default values from, will have to try and do some digging.

Since you are using the esp-idf-* ecosystem you should have the generated partition table for your application available somewhere, in the target/ directory somewhere if memory serves me correct. In the meantime you can specify this partition table as a command-line argument and this should hopefully resolve the issue. Alternatively, you can create your own partition table with an appropriately sized factory partition and use this.

We have some machinery in place in cargo-espflash which automatically picks up on this generated partition table when using the esp-idf-* ecosystem, however this is not currently available in espflash. I would like to try to port this functionality over, so will look into the feasibility of doing so.

[armandas]

Thanks for the feedback. Since the tool correctly prints out the actual flash size, would it not make sense to override the default with that?

I have since added the partition table as it was needed for OTA, but I imagine many projects may not need it, so it would be nice of the tool worked without it.

[empirephoenix]

I was also able to trigger it somewhat reliable
Using a partition table I was also able to work around this, but it is kinda funny that I need a partition table if I only build an image :)
https://git.mannheim.ccc.de/C3MA/PlantCtrl/src/branch/develop/rust/Cargo.toml#L25