Closed nosuz closed 1 year ago
uh strange, can you past the device's bootloader version (aka BTVER), it is usually printed after the isp key is setup... (I should change that)
You can use the list
command to show the BTVER info without setting up the isp key, can you try this ?
$ wch-isp list
Also could you paste the first 10 lines when using wch-isp -D zig-out/firmware.bin
on CH32V203C8T6
(the device that works)
cheers
Sure.
The BTVER is 2.7 as follows.
$ wch-isp list
0: BTVER v2.7 UID cd-ab-66-67-55-bc-88-cf [0x1932] CH32V203K8T6
And the debug output from CH32V203C8T6
is
$ wch-isp -D flash zig-out/firmware.bin
isp send cmd a1 len 0012 : 00004d4355204953502026205743482e434e
isp recv cmd a1 len 0002 : 3119
isp send cmd a7 len 0002 : 0800
isp recv cmd a7 len 0006 : 080000020600
isp send cmd a7 len 0002 : 1000
isp recv cmd a7 len 000a : 1000cdabb88745bccaef
isp send cmd a3 len 001e : 000000000000000000000000000000000000000000000000000000000000
isp recv cmd a3 len 0002 : b900
isp send cmd a4 len 0004 : 01000000
isp recv cmd a4 len 0002 : 0000
I hope this can help.
the device that works has a bootloader version 2.6, while the other device has version 2.7
the function isp_key_init
has a different behavior if the device has a BTVER >= 2.7
, see:
https://github.com/jmaselbas/wch-isp/blob/c0d425f6d576763fe3ff3026853d7ff4bad75efd/wch-isp.c#L556
In your case the "BTVER 2.7" behavior seems not appropriated, you could try to modify this function to disable this case (only keep the 2.6 behavior) and see if it "fixes" your issue. This will not be a proper fix, for that I need to know on which condition the "new"/BTVER_2.7 behavior is expected.
for the record, the different behavior on BTVER 2.7 was to support the CH569 and maybe this quirk should only be selected on that device (not dependent on BTVER)... but I don't know
Thank you for your advice.
I rewited wch-isp.c
as follows to skip the bootloader version check and worked fine.
diff --git a/wch-isp.c b/wch-isp.c
index 34dd170..c2c3583 100644
--- a/wch-isp.c
+++ b/wch-isp.c
@@ -553,16 +553,8 @@ isp_key_init(struct isp_dev *dev)
/* send the isp key */
isp_cmd_isp_key(dev, sizeof(isp_key), isp_key, &rsp);
- if (dev->btver >= BTVER_2_7) {
- /* bootloader version 2.7 (and maybe onward) simply send zero */
- sum = 0;
- } else {
- /* bootloader version 2.6 (and maybe prior versions) send back
- * the checksum of xor_key. This response is used to make sure
- * we are in sync. */
- for (sum = 0, i = 0; i < sizeof(dev->xor_key); i++)
- sum += dev->xor_key[i];
- }
+ for (sum = 0, i = 0; i < sizeof(dev->xor_key); i++)
+ sum += dev->xor_key[i];
if (rsp != sum)
die("failed set isp key, wrong reply, got %x (exp %x)\n", rsp, sum);
}
I reworked the workaround, this issue should be fixed by ebd426006050775778121f22394403e758af9a5d
Thank you for fixing the issue. I confirmed the current main branch works fine.
I got the next error message on flasing for CH32V203K8T6.
wchi-isp works fine for CH32V2023C8T6. And the other ISP program wchisp works for CH32V203K8T6.