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

[basilhussain]

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]

Thanks.

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

[basilhussain]

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

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.