write-bin truncates data when length not divisible by 4

[zargony]

It seems that write-bin truncates data to full 256 bytes blocks when length of data is not divisible by 4.

I.e.:

• any data with length divisable by 4 is flashed correctly
• any data with length not divisable by 4 gets truncated to full 256 bytes blocks

Some examples:
64 bytes -> ok
66 bytes -> nothing flashed (all 0xff)
256 bytes -> ok
258 bytes -> truncated to 256 bytes
260 bytes -> ok
262 bytes -> truncated to 256 bytes

Analysis

Looking through espflash code (Esp32Target), I couldn't find the cause for this issue. I suspect this has something to do with how the stub decompresses data or handles chunks of data. And indeed the issue doesn't happen when using --no-stub. It might even be a (known?) limitation of the stub, however neither documentation nor code seems to mention it anywhere.

This sounds like it would need to be fixed in the stub code (which is precompiled binary, so no idea if it can be modified). It could also be worked around in espflash by padding data to length divisible by 4 before compressing and sending it to the stub.

My environment: ESP32-C3, Rust 1.82.0, espflash 3.2.0, macOS 15.0 (24A335)

Steps to reproduce

• create a file with 262 bytes (not divisible by 4)
• flash it (espflash write-bin 0xc000 foo.txt)
• read it back (espflash read-flash 0xc000 0x1000 foo.bin)
• compare and see it truncated to length 256 (filled with 0xff)
• repeat with 260 bytes (divisible by 4): ok
• repeat with 262 bytes and --no-stub: ok

[zargony]

I tried the same with esptool.py: it works fine with any data length. I noticed it says "Wrote 240 bytes" when writing a file with 238 bytes of data. It seems to use the same above mentioned workaround (here) and pads data to be divisible by 4.