search

ch32-rs / wchisp

Rust-based Command Line Tool for WCH MCU USB-ISP Programming
https://ch32-rs.github.io/wchisp/
GNU General Public License v2.0
181 stars 30 forks source link

Why are firmware images extended to nearest flash sector boundary with 0x00 value? #57

Open basilhussain opened 2 months ago

basilhussain commented 2 months ago

Is there a specific reason why, when a firmware image is being written to flash (or verified), and the firmware image needs to be extended in size to the nearest 1K sector boundary (in function extend_firmware_to_sector_boundary()), is the extended space filled with 0x00 bytes and not 0xFF?

Is it done this way simply to replicate what the official WCH ISP software tools do?

I believe it would be better to fill the extended space with 0xFF because using any other value (i.e. one that differs from flash memory's erased state) will unnecessarily wear the flash memory.

While I appreciate that this is a minor concern in the grand scheme of things, I do think it would help if development tools such as wchisp do not unnecessarily do things that risk quicker degradation of the user's hardware than there would otherwise be.

andelf commented 2 months ago

Thanks.

This might be a design pitfall. I need to check the behavior of WCHISPTool.exe.

basilhussain commented 2 months ago

I compared downloading the same firmware binary with WCHISPTool (v3.60) to wchisp. WCHISPTool does not extend or pad with 0x00.

image

Of course, it's impossible to tell if it's using 0xFF or actually not doing any padding at all. But then the difference is meaningless - same result. 😄 And I don't know what that extra 8-bytes of whatever at offset 0x278 is.