Usually I am working with WCHISPTool v2.6 but that bug also exists in v3.2 Sometimes I get verify errors when downloading new code although it seems the code is downloaded correctly.

Actually i use CH552 chips with bootloader 2.31. It seems this just happens when there is allready a bigger code in flash than the new download one. If I create a firmware with all bytes 0xFF a new download will be without verify errors.

While the download still seems fine its anoying to see those verify errors. I dont know if this is just a problem of v2.31 (dont have v2.4 chips), but i cant remember seeing this with v1.1 chips.

In this case, how many bytes is the larger firmware, and how many bytes is the smaller firmware?

I will try to compare the downloading of the V2.31 and V2.4 version of the chip according to different lengths.

Thanks for responding, 

I have atached 2 hexfiles. The midi.hex code is the bigger one. If you flash this first to a v2.31 CH552, flashing the the vcp hex fails with verify error. 

example.zip

Here is a second example where the bug does not occur. 

Both hex files are created using the same source. The Keil version is about 15% less than the SDCC version.

example2.zip

I hope this helps to nail down this bug.

I use the WCHISPTool to  download and verify it is no problem.

What tools did you usb to download the HEX file?WCHISPTool or others?

Now I am using WCHISPTool v3.2 but before v2.6 in usb mode. The error occures with the files from post #3 and with CH552 with v2.31 bootloader.

1. download mididemo_sdcc.hex to the chip

2. download CDC_NEW.hex -> verify error

I will try to capture the the relevant bulk requests later. Meanwhile i have done tests with v1.1 loader there all is fine. 

As said i cant test with v2.4 chips.

Here a capture of the bulk request. It looks like the first verify fails @0x0000, maybe because of the extra two 0x00 bytes before the encoded data start.

Have you tried to replace another chip?

It is best not to mix different versions of WCHISPTool.

I have checked that with a brand new chip. Its working. So I am guessing now it has something todo with the UUID of that paricular chip. So mybe its not a problem of the codesize but some problem with the calculated downloadkey.

Have you tested whether the function of the flash of that particular chip is correct? Especially whether the flash between 3.08KB and 3.57KB(the difference between the two files in 3#) can write 1 or 0?

ok i did some extensive testing today using a asm macro for all bytes 0xFF or 0x00

cseg at 0

rept (0x3800)
    DB  0x00
endM
end.

all 0xFF fails all 0x00 is ok. So it seems i have some flash wear out problem. Never had seen that before. I am relatively sure i did not meet the 200 cycles up to now.

But now the strange thing. If i read back the flash contents with my own software the dump is still correct.