Upload Failing Windows 10 (WCH-LinkE)

[prairielandelec]

Just got a CH32C0003F4P6-Ro-1v1 and a WCH-LinkE-Ro-1v1 and am attempting to upload a test sketch.

First I installed the board packed per the instructions in this repo

I have connected SWDIO to PD1 on the dev board as well as 3v3 and GND and RX to PD5

When I look at Device manager there is a USB Serial Device and an unknown device WCH-Link

I select the USB Serial Device as the port in the Arduino IDE and the CH32V00x as the board and put in a simple blink test.

When I click "upload" I get the following:

Sketch uses 4796 bytes (29%) of program storage space. Maximum is 16384 bytes.
Global variables use 396 bytes (19%) of dynamic memory, leaving 1652 bytes for local variables. Maximum is 2048 bytes.
Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2023-05-05-13:43)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Failed uploading: uploading error: exit status 0xc0000005

Is this just a faulty WCH-LinkE? Or am I missing some step of the initial configuration process? The bin builds just fine but after this error shows up nothing happens.

Thanks!

[maxint-rd]

I think you're missing some driver. In my Windows 11 system I see both a USB Serial COM port and under Interfaces a WCH-LinkRV device. The latter I believe handles the SWIO pin for programming and real-time debugging, while the COM port allows showing output from Serial.println() and input via Serial.read().
(For flashing the chip the debugging port is used).

[prairielandelec]

It would appear that is the case, I could not find any instructions in this repo and scant documentation in general. My understanding was that the WCH-LinkE utilized the OpenOCD drivers to some degree. I was looking through the Platoform IO Platform for this chip and saw the following section of their documentation:
https://pio-ch32v.readthedocs.io/en/latest/installation.html#install-drivers-rules

I tried this driver on a spare laptop I had and it seemed to get things working. Biggest difference was seeing the WCH-Link interface appear in the "interfaces" section of device manager. I was able to program the following to the chip:

void setup() {
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_PIN, HIGH);
  delay(100);
  digitalWrite(LED_PIN, LOW);
  delay(100);
}

The verification check seemed to pass just fine, however I do not see the output toggling on any of the pins. Is there any documentation on the pin naming? From what I can tell from other examples I have configured everything correctly.

Just trying to pinpoint if this is a problem with the flashing process, the code, or the chip on my dev board.

Thanks for the help!

[maxint-rd]

There are some cheat sheets that show the pinouts of the various chips. For the F4P6 I made a PDF out of the image I found somewhere: ch32v003f4p6_pinout.pdf

Usually I use pin names such as PC1, PA1, etc.
Have fun!

[TianpeiLee]

When using wch-linke, it is important to ensure that the driver for wch-linke is installed correctly and that its firmware version is the latest. This can be done through the "WCH LinkUtility" tool to install the driver and update the firmware.
https://www.wch.cn/downloads/WCH-LinkUtility_ZIP.html

In addition to using pinout diagrams similar to those provided by maxint-rd, there is also an imperfect way to query through the file "variantCH32V003F4.cpp" and the RM

[ITstreet1]

I have a similar problem, but with the CH32L103C8T6. The WCH-LinkE firmware is up to date. While I try to upload a simple Blink sketch, I get:

Sketch uses 7896 bytes (12%) of program storage space. Maximum is 65536 bytes.
Global variables use 476 bytes (2%) of dynamic memory, leaving 20004 bytes for local variables. Maximum is 20480 bytes.
Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2023-05-05-13:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : WCH-LinkE mode:RV version 2.12
Error: communication fail,please contact [support@mounriver.com]

Failed uploading: uploading error: exit status 1

What to check?

[maxint-rd]

Can you try the WCH Link Utility? Using the utility you can connect and read chip information. If that succeeds, you should also be able to use features such as Power on erase and also program it using the binary that the Arduino IDE generated.
If reading chip info fails, you need to make sure you selected the correct chip and check your connections.
If needed update that WCH Link Utility to the latest version also.

Unfortunately I don't own any 10x chips, so I can't help you in testing things.

[ITstreet1]

The utility can detect the chip, and I can upload the HEX file created by the Arduino IDE. Still, I can not upload the code using the Arduino IDE. Do I need to set a thing or two more in IDE? I use all default settings and the WCH SWD upload method.

I am using 2.3.6 IDE

[maxint-rd]

Being able to use the Link Utility is already good news. That means that hardware is working and properly connected.
In the IDE you need to make sure you have the CH32L103C8T6 selected. You probably already selected the right one, since Flash/RAM size match what's mentioned in the datasheet.

For the V002/V006 I needed to also update the WCH build of OpenOCD. I'm not sure if that will make it work for you. In this readme that I made for PR #200, you can read how I updated to WCH OpenOCD v2.3.
BTW. I'm using the same upload method.

Oh, if you make changes to board.txt/plaftform.txt you also need to clear IDE cache and restart.

[ITstreet1]

Ok,
So, I did all of your suggestions. The sketch uploads to the board, and it works. But, here is what it spill out:

Sketch uses 7896 bytes (12%) of program storage space. Maximum is 65536 bytes.
Global variables use 476 bytes (2%) of dynamic memory, leaving 20004 bytes for local variables. Maximum is 20480 bytes.
Open On-Chip Debugger 0.11.0+dev-snapshot (2025-07-15-14:40)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : WCH-LinkE mode:RV version 2.12
Info : wlink_init ok
Info : clock speed 6000 kHz
Info : [wch_riscv.cpu.0] datacount=2 progbufsize=8
Info : [wch_riscv.cpu.0] Examined RISC-V core; found 1 harts
Info : [wch_riscv.cpu.0] XLEN=32, misa=0x40901105
[wch_riscv.cpu.0] Target successfully examined.
Info : starting gdb server for wch_riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
** Programming Started **
Info : device id = 0x63edabcd
Info : flash size = 64kbytes
** Programming Finished **
** Verify Started **
Error: Algorithm timed out after 20001 ms.
Error: ra = 0x18b6
Error: sp = 0x20004fc0
Error: gp = 0x20000930
Error: tp = 0xcbf28f0b
Error: t0 = 0x75c
Error: t1 = 0xff0fffff
Error: t2 = 0x98993057
Error: s0 = 0x7d0
Error: s1 = 0x4650
Error: a0 = 0x7b9
Error: a1 = 0x0
Error: a2 = 0x0
Error: a3 = 0x20000000
Error: a4 = 0x1
Error: a5 = 0x2000
Error: a6 = 0x3
Error: a7 = 0x8000
Error: s2 = 0x4fd82384
Error: s3 = 0xdf8e8e16
Error: s4 = 0x4ef80000
Error: s5 = 0xc3e0ad65
Error: s6 = 0xebfdc690
Error: s7 = 0xeb1cc804
Error: s8 = 0xc9798226
Error: s9 = 0xcfba8b1e
Error: s10 = 0xcf7b5066
Error: s11 = 0x5df89201
Error: t3 = 0x10
Error: t4 = 0x1
Error: t5 = 0xf
Error: t6 = 0x28
Error: pc = 0x75c
Error: mstatus = 0x88
Error: mepc = 0x19a
Error: mcause = 0x8000000c
Error: error executing RISC-V CRC algorithm
** Verified OK **

[maxint-rd]

Good to know that updating OpenOCD made some difference.
Thanks for sharing your findings. That may come in handy for others with similar setup.

It's quite a list of messages you got. In my most recent tests with V002/V003/V006 and X033, I sometimes got one or two messages after successful verification. Never such a long list of errors before that OK message. Unfortunately I don't have a CH32L103 (or V103) to check your findings, so I can't confirm. @KenRouKoro did some recent testing on his V103, but didn't mention such errors. They all seem to relate to registers, perhaps their values are different from expected.

If I were you I would now test these things:

• check the wires to see if they cause noise. In my latest tests I used a flaky breadboard with rather long jumper wires. Sometimes uploading failed and the Link Utility didn't recognize the chip. Reinserting SWDIO/SWCLK fixed it.
• Use the Link Utility to upload the generated binary and see if the verify step reports any errors
• Try out the real-time debugging within the Arduino IDE to check if it reports any errors. (If no errors: happy debugging and developing!)

[KenRouKoro]

I have encountered this problem before. You may have used a long dupont cable to connect your MCU. I recommend using MounRiver Studio for programming, as the programming success rate is significantly higher than using OpenOCD in my tests. Moreover, it has more powerful functions. Also, if programming fails, it's best to unplug and replug the WCHLinkE (which is also the debugger I use).

[KenRouKoro]

I have tested 10cm and 20cm DuPont cables. The 20cm DuPont cable will completely fail to program (verification failed) for a period of time (it's very sudden that there will be a period of time), and then it will be permanently unable to program, at which point the WCHLinkE needs to be re-plugged. However, the 10cm one has none of these problems.