Description
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
Metadata
Metadata
Assignees
Type
Projects
Status