Reworked most #21
Reworked most #21
Conversation
|
Sorry if it a bit wrong, it's my firs PR , would like to discuss many things like:
Could contact me in real chat via Telegram (look for same nickname) or at channel ch55x ( t.me/ch55x ) |
|
Also would like to add additional "readme" where protocol could be described and possibly related researches. |
|
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. |
|
Great jobs! Let me know when you finish. Then I can test and push a new pip package :p |
…frocessing fix. Removed printout of wrong maximal packet size.
…human readable format.
…d with parameter to restart or not.
…nd need be >= 2.3
…chips dictionary initial definition.
…mpty file is given. Command line parameters, all of them could work individualy : -f/--flash <filename> Flashing file, include chip erase, <filename> is mandatory. -e/--erase_flash Erase whole program flash. --verify_flash [filename] Perform program flash verifying with given file, [filename] is optional and if ommited perform verifying with flashed program. -r/--reset_at_end Perform chip reset and program run at the end of communication.
Added command lines and related functions, all those additional work individualy too.: -g/--read_dataflash <filename> -d/--data <filename> -c/--erase_dataflash --verify_data [filename]
|
@MarsTechHAN so I finish for now, I think. I also updated README.md a bit. Please check and comment. |
Fix command for data flash erase.
|
@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.
|
|
Yes, sure, I will fix it right now (I copied it from #22 without check, but yes, it is wrong). |
…inal "WCHISP/ChipType/typeall.wcfg" INI type file.
|
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) |
|
Thanks, good news :) |
|
This version also fails on my CH582M bt 2.40 The binaries can be loaded ok using MounRiver Studio's binary openocd. It works just fine on my ch32v307 board, as my version does. 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. |
|
@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 |
|
well, that still seems like something that should be able to handle :) |
|
If you're able to use OpenOCD to write to it, according to the datasheet 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. |
|
well, fwiw, in windows WCHISP v3.2, it still showed as "enable code and data protection" ticked, so not sure? |
|
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? |
|
@karlp I think thats just the default settings and doesn't reflect the state the device is currently in? |
|
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: The 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): |
@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. |
|
@karlp thanks for reporting failure, we definitely should investigate on this.
@karlp About protocol, it's mostly clear with next exceptions:
@pablomarx Thanks for pointing to information about configuration bits, you are right it is one of my targets. My next plans for release:
Plans, but should we put those in release ?? :
|
… need to pass value from 0 to 255 (meaning not known). For test purposes only.
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 If you wanted to go that route, I can produce the values for CH571/573/579/582. |
|
@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 : I'm ready to prepare processing of it. |
|
About researches, one more thing to clarify is: |
…onal user file. Passing config option in command line (test/simulation). Added: - processing of extended chip defines and with possible parameters "Tested" and config bits "CFGs" , see example in extended.wcfg - command line parameter '-u' to pass additional user file with chip defines / extended defines. - added command line parameters "-o / --cfg_options" and "-a / --cfg_options_after" (only first implemented simulation). Accept repeated use with space and comma separated options.
…eed special option to force real action. Manu other bug fixes.
|
Here's the output when ran with a CH32V307 64-pin version: Can also confirm that after changing the chipid for V307 in |
| } | ||
|
|
||
| # Meaning of those two values not yet clear :( | ||
| DETECT_PL_START = b'\x42\x10' |
There was a problem hiding this comment.
first is ChipId
the second is DeviceType
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
And still a bit unclear why:
for CH552 it is 0x52
but
for CH568 it is 0x42 (not 0x68)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I finally built a WCH chip DB from all available information, embedded in my tool:
There was a problem hiding this comment.
It's huge positive push for me to migrate to those configs :)
Never worked with YAML before but looks like it's time start.
There was a problem hiding this comment.
Hope it helps.
now it can recognize my CH32V307 chip's variants correctly. (flash size matters for erase command).
|
It's known that DeviceType starts from 0x10 value (as reported by Patrick Yang from WCH). |
|
There is newer WCHISPTool (from 26 Apr. 2022) so chip list will going to be updated. |
|
@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 |
|
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: 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, |
|
@trcwm Actually, typeall.wcfg is just a reference config file. There're still many hidden parts in the WCHISPTool program. 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. I tried to implement the device selection logic in https://github.com/ch32-rs/wchisp. |
Hi this rework targets:
Were testing on 3 ICs: CH568 (working program) , CH552 and CH559 with random files.