Reworked most

[Pe3ucTop]

Hi this rework targets:

• unify commands and it parameters, so in theory those later could try not only through USB but Serial as well,
• add CH568 support
• add key generation for programming and verification which is depend on chip type, so work for both CH55x and CH568 (possibly CH56x and others)
• changed erase command and parameter, erase full flash, depend on chip type
• added functions to read/write configuration settings, settings will follow.
• combined / simplified flash write and verify and boot loader version dependence, there is no such (all old split commands follow single protocol)
• sorry, switched to tab delimiter, can rework it back.

Were testing on 3 ICs: CH568 (working program) , CH552 and CH559 with random files.

[Pe3ucTop]

Sorry if it a bit wrong, it's my firs PR , would like to discuss many things like:

• adding Data EEPROM erasing/writing/reading (verification is by comparing written and later read out)
• command lines parameters for Data EEPROM passing, adding offset parameter and read out to file
• options passing, similar to original SW checkbox, how to store those and list out for usage

Could contact me in real chat via Telegram (look for same nickname) or at channel ch55x ( t.me/ch55x )

[Pe3ucTop]

Also would like to add additional "readme" where protocol could be described and possibly related researches.

[Pe3ucTop]

And from original WCHISP there is text file which describe all chipsets/sizes/id codes, we can convert it to WCH_IC dictionary with additional flag like tested/theoretical support.

[MarsTechHAN]

Great jobs! Let me know when you finish. Then I can test and push a new pip package :p

[Pe3ucTop]

@MarsTechHAN so I finish for now, I think. I also updated README.md a bit. Please check and comment.

[pablomarx]

@Pe3ucTop Can you change the flash size of the CH579 from 256KB to 250KB? The erase fails with 256KB as the last 6KB isn't erasable.

[Pe3ucTop]

Yes, sure, I will fix it right now (I copied it from #22 without check, but yes, it is wrong).
Probably, I will convert initial parameters to be taken from original "WCHISP/ChipType/typeall.wcfg" INI file in near time.

[pablomarx]

This PR works for me with the following: CH571F(02.80), CH573F(02.70), CH579F(02.70), CH579M(02.61), CH582M(02.40), and CH32V103(02.60).

It works for my CH549F(02.40) but it requires me to manually change the USB_MAX_TIMEOUT to a larger value in order for the erase to succeed (a value of 5000 seems to be reliable)

[Pe3ucTop]

Thanks, good news :)
Ok, I will update USB_MAX_TIMEOUT to 5000 right now.
@pablomarx Small question: did you tried data flash read/write/erase/verify as well or only program flash ?

[karlp]

This version also fails on my CH582M bt 2.40

karlp@beros:~/src/wch-ch552tool (pe3uc-alt)$ python -m ch55xtool -f ~/src/l2-krv-miniblink/miniblink1.bin 
Found CH582 with SubId:22
BTVER:02.40
UID:0D-1C-34-26-3B-38-7C-7A
Erasing chip flash. Done.
Failed to flash firmware of CH55x.
Flashing chip.

The binaries can be loaded ok using MounRiver Studio's binary openocd.

It works just fine on my ch32v307 board, as my version does.

karlp@beros:~/src/wch-ch552tool (pe3uc-alt)$ python -m ch55xtool -f ~/src/l2-krv-miniblink/sample-pa01-blink-both-faster.bin 
Found CH32V307 with SubId:23
BTVER:02.60
UID:7A-1D-3E-26-3B-38-F3-7B
Erasing chip flash. Done.
Flashing chip. Done.
Finalize communication. Done.

I tried a few versions of this, forcing the 8 byte checksum, forcing the v26 key, but never made any progress beyond erasing (which seems to work) on the ch582M board.

[pablomarx]

@karlp I believe this is due to the current configuration the CH582M is in, especially if you're able to write with OpenOCD. In my experience I can't even flash it with WCHISPTool unless "Enable code and data protection mode" is enabled, as demonstrated in this screencast:

WCHISPTool_CH582.mov

[karlp]

well, that still seems like something that should be able to handle :)

[pablomarx]

If you're able to use OpenOCD to write to it, according to the datasheet CFG_ROM_READ would be 1 – and it seems the bootloader fails to write unless CFG_ROM_READ is 0.

And agreed – I'd love for this tool to be able to twiddle the configuration bits, or failing that set known good values on problematic devices like the CH582. And it looks like @Pe3ucTop is headed that direction with the ability right now to print out config values.

[karlp]

well, fwiw, in windows WCHISP v3.2, it still showed as "enable code and data protection" ticked, so not sure?

[karlp]

How much of the protocol have you guys got figured out from elsewhere? Is there any point in me starting up a wireshark decoder for the protocol, or is it well "enough" understood at this point?

[pablomarx]

@karlp I think thats just the default settings and doesn't reflect the state the device is currently in?

[pablomarx]

Re: the protocol, the config bytes will come back in an A7 / READ_CFG_CMD_V2 / ReadConfig and can be written with an A8 command.

For the CH582, this is a read config response I just captured with the three config words separated:

a7001a001f00_ffffffff_23000000_d50fff4f_000204001e1934263b388d77

The d50fff4f is of interest here, and breaks down into (based on the earlier screenshot from the datasheet I shared):

d50fff4f = 11010101_00001111_11111111_01001111
           |||||^^^ bit2~bit0 RESERVED 101b 
           ||||^ bit3 CFG_RESET_EN
           |||^ bit4 CFG_DEBUG_EN
           ||^ bit5 RESERVED 0
           |^ bit6 CFG_BOOT_EN 
           ^ bit7 CFG_ROM_READ 

That should correspond to being able to write firmwares with OpenOCD.

And then capturing an packet writing a new config (switching it back to where the ISP Tool can write to it):

a80e000700_ffffffff_03000000_4d0fff4f

4d0fff4f = 01001101_00001111_11111111_01001111
           |||||^^^ bit2~bit0 RESERVED 101b 
           ||||^ bit3 CFG_RESET_EN
           |||^ bit4 CFG_DEBUG_EN
           ||^ bit5 RESERVED 0
           |^ bit6 CFG_BOOT_EN 
           ^ bit7 CFG_ROM_READ 

[pablomarx]

Small question: did you tried data flash read/write/erase/verify as well or only program flash ?

@Pe3ucTop I only tried programming files – I hadn't even noticed you added separate commands. I'm excited to check out the read command – I'll try those out in a few hours and let you know.

[Pe3ucTop]

@karlp thanks for reporting failure, we definitely should investigate on this.
More possible reasons of fail:

• In WCHISP for CH58x is field "WProtect Addr: 0~0x" maybe it was somehow written once so now fail to write.
• I just remembered is "minimal erase amount", saw it in disassembled WCHISP , it was something 8kb or 4kb (8 or 4 pages) with some dependencies. But it should not be our case because we erase all.
• and yes, other configs as @pablomarx reported.

@karlp About protocol, it's mostly clear with next exceptions:

1. CFG1/2/3 bits meaning, I figured out some for chips I have CH552/9, CH568 and for CH552/9 same meaning checkbox differ in bit, unclear dependence on chip or BT ver. (which differ in my case, 2.40 and 2.31)
2. Data(EEPROM) erase command not clear, so should investigate on it. Parameter of it is 5 bytes: 4 zeroes and 1 byte size in ?? kb or pages.

• so meaning of those 4 zeroes unclear
• how we should erase if size is less than 1kb ?

3. How to differentiate chips with same ChipID , noticed there is such problem in chip definition file.
4. WCHISP have fields "Run IAP", "IAP Start Addr" and "IAP File" , but do not know what it is and file to put there, but would like to figure it out.
5. I saw some extra commands in disassembled WCHISP for operating with OTP , but do not see anything related in WCHISP and do not know applicable chips.
6. !! USB packet size (now extracted from descriptor, saw only 64) in theory for HS up to 1kb, SS even bigger, but in disassembles code every where up to ~514..516 (not 512) , so need find chip with mentioned case (HS USB BootLoader) :)

@pablomarx Thanks for pointing to information about configuration bits, you are right it is one of my targets.

My next plans for release:

• investigate on Data flash(EEPROM) erase
• add more informative Fail report like address(region) it fail on

Plans, but should we put those in release ?? :

• possibly to put some additional command line options like: --set_reset_cfgs_before / after flashing, to come close to CFGs bits meaning and more human readable format for those.
• read out and print OTP to look on it :) at least
• add additional INI files processing to be able to define more needed chip parameters, like known CFGs bit meanings, Chip support status (tested/warning/..), etc..

[pablomarx]

Plans, but should we put those in release ?? :

• possibly to put some additional command line options like: --set_reset_cfgs_before / after flashing, to come close to CFGs bits meaning and more human readable format for those.

It is very easy to get the CH582 and CH579 into a state where the tool can no longer flash them, and then you have to go to Windows to fix it. I think at a minimum a --recover flag that applies a hardcoded config to the device would be nice (and familiar to people that have used nrfjprog), and it seems easy enough to store in the ini file, e.g.:

[CH582]
 McuType=6
 MaxFlashSize=458752
 MaxEepromSize=32768
 IsNetworkDown=0
 IsUsbDown=1
 IsSerialDown=1
 chipid=130
 eepromStartAddr=0
 Introduction = ""
 Recovery=ffffffff030000004d0fff4f

If you wanted to go that route, I can produce the values for CH571/573/579/582.

[Pe3ucTop]

@pablomarx thanks, Yes, why not, but I would like to not modify existing original definition file but put another one with extended defines, updates and "user" defines. If you could prepare file with contents like :

[CH582]
Tested=True
Recovery=0xffffffff, 0x03000000, 0x4d0fff4f

[CH571]
Tested=yes
Recovery=....

[CH573]
Tested=1
Recovery=....

I'm ready to prepare processing of it.

[Pe3ucTop]

About researches, one more thing to clarify is:
After which operations device stop respond to repeated detection and which operations return back to normal op.
It's not critical, but is nice to have ability make sequential execution of program without device reset.
I noticed small regression on it.

[arturo182]

Here's the output when ran with a CH32V307 64-pin version:

Found CH571 with SubId:23
BTVER:02.60
UID:FD-B0-3E-26-3B-38-76-0F
Finalize communication. Done.

Can also confirm that after changing the chipid for V307 in typeall.cfg from 112 to 113, I managed to flash and verify my board. While I know that fix is not production-quality, it was the only change needed for the V307 64-pin to work with this PR :)

[andelf]

first is ChipId
the second is DeviceType

[Pe3ucTop]

Thanks, yes, it's the same as ChipId/DeviceType of chosen type in WCHISP.
It's still a bit unclear in which sequence those get selected when try to identify unknown chip.

[Pe3ucTop]

I tried to switch boards and detect another chip and detection change those values in some order.
I switch from CH568 to CH552 and detection still was working even with wrong values.

[Pe3ucTop]

And still a bit unclear why:
for CH552 it is 0x52
but
for CH568 it is 0x42 (not 0x68)

[andelf]

My test has the following conclusions:

All CH56x family chips have chip_id = 0x42. when you see a 0x42, it must be one of CH56x.

[Pe3ucTop]

Which chip you work with ? Is it CH563 ?
From reverse engineering of WCHISPTool I have:

      switch ( ... )
      {
        case 0:
        case 0x46:
        case 0x61:
          LOBYTE(dword_100240BC) = 70;
          strcpy(Str, aCh561);
          break;
        case 1:
        case 0x42:
        case 0x63:
          LOBYTE(dword_100240BC) = 66;
          strcpy(Str, aCh563);
          break;
        case 2:
        case 0x65:
          LOBYTE(dword_100240BC) = 101;
          strcpy(Str, aCh565);
          break;
        case 3:
        case 0x66:
          LOBYTE(dword_100240BC) = 102;
          strcpy(Str, aCh566);
          break;
        case 4:
        case 0x67:
          LOBYTE(dword_100240BC) = 103;
          strcpy(Str, aCh567);
          break;
        case 5:
        case 0x68:
          LOBYTE(dword_100240BC) = 104;
          strcpy(Str, aCh568);
          break;
        case 6:
        case 0x69:
          LOBYTE(dword_100240BC) = 105;
          strcpy(Str, aCh569);
          break;
        default:
          break;
      }

and CH568 I have report it ID as 0x68 , but yes, detection request is going with 0x42 .
And it response with correct id to 0x68 request too.

[andelf]

I finally built a WCH chip DB from all available information, embedded in my tool:

https://github.com/ch32-rs/wchisp/tree/main/devices

[Pe3ucTop]

It's huge positive push for me to migrate to those configs :)
Never worked with YAML before but looks like it's time start.

[andelf]

Hope it helps.
now it can recognize my CH32V307 chip's variants correctly. (flash size matters for erase command).

[Pe3ucTop]

It's known that DeviceType starts from 0x10 value (as reported by Patrick Yang from WCH).
DeviceType = ChipSeries = McuType (+0x10 from typeall.wcfg)
I plan to implement chip selecting dependency on it too near time.

[Pe3ucTop]

There is newer WCHISPTool (from 26 Apr. 2022) so chip list will going to be updated.
But unfortunately that file (typeall.wcfg) do not represent all chips still nor chip model/package/postfix like CH32V307VCT6 and CH32V307RCT6 which have different DeviceType/ChipId .
Also such file format have limitations - Sections could not repeats to extend previous.
I'm going to switch to another chip database file format probably.

[andelf]

@pablomarx @Pe3ucTop I added a basic config register parsing(via YAML definition, will have resetting/unprotecting support soon) to https://github.com/ch32-rs/wchisp

It will be very helpful if you can provide any resetting values or register maps for CH5xx chips.

The tool outputs like this:

> wchisp info
14:51:24 [INFO] Chip: CH32V307VCT6[0x7017] (Code Flash: 256KiB)
14:51:24 [INFO] Chip UID: 30-78-3e-26-3b-38-a9-d6
14:51:24 [INFO] BTVER(bootloader ver): 02.60
14:51:24 [INFO] Code Flash protected: false
RDPR_USER: 0x9F605AA5
  [7:0] RDPR 0b10100101 (0xA5)
    `- Unprotected
  [16:16] IWDG_SW 0b0 (0x0)
    `- IWDG enabled by the software
  [17:17] STOP_RST 0b0 (0x0)
    `- Enable
  [18:18] STANDBY_RST 0b0 (0x0)
    `- Enable
  [23:21] SRAM_CODE_MODE 0b11 (0x3)
    `- CODE-228KB + RAM-32KB
DATA: 0x00FF00FF
  [7:0] DATA0 0b11111111 (0xFF)
  [23:16] DATA0 0b11111111 (0xFF)
WRP: 0xFFFFFFFF
  `- Unprotected

[trcwm]

Hi,

Thanks for making this project and the PR.

I tried this with my CH32V103 dev board. It said the ID=3F is unknown. Indeed, the CH32V103 ID listed in typeall.wcfg is 50, not 63. After changing this, I got some useful output:

Found CH32V103 with SubId:21
BTVER:02.60
UID:CD-AB-3D-87-49-BC-53-EF
Finalize communication. Done.

Incidentally, the ID listed for CH32F103 also 50. Could the ID for the CH32V103 in the current typeal.wcfg be wrong?

The exact chip I am using is CH32V103R8T6.

Regards,
Niels.

[andelf]

@trcwm Actually, typeall.wcfg is just a reference config file. There're still many hidden parts in the WCHISPTool program.
CH32V10x and CH32F10x are such hidden examples.

For CH32V10x, ID=0x32 is CH32V103C6T6, which is a 32K flash device. For all the other cases(id is ignored), the MCU will be recognized as a 64K flash device, either CH32V103(C8T6|C8U6|R8T6). they are the same.
You might refer https://github.com/ch32-rs/wchisp/blob/main/devices/0x15-CH32V103.yaml
The same goes for CH32F10x.

I tried to implement the device selection logic in https://github.com/ch32-rs/wchisp.