Open basilhussain opened 1 month ago
Thanks.
This might be a design pitfall. I need to check the behavior of WCHISPTool.exe.
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.
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 with0x00
bytes and not0xFF
?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.