Months ago, when I was looking at LCSC, and spotted the CH32V203 in the listing, cheaper then the CH32V103. A higher number implies a better product, right? And when it’s even cheaper. So, I ordered a few, and soldered them to my PCB. (The design I use to compare all the *32?103C?T? chips) Back then, I was looking into the pricing of *32?103 variants. Perhaps I should look at the pricing agian, see how it changed since May.But that’s now what I want to talk about today.
So, back then, I ordered some of those chips, soldered them to my board. But I had issues debugging them. Now, WinChipHead, or Nanjing Qinheng Microelectronics, uses some custom debugging protocol. They provide a toolchain including an OpenOCD fork, which is either bundles with the MounRiver IDE, or downloaded stand-alone.
Since OpenOCD is GPL licensed, they’re required to release their source upon request. Last summer, someone requested the source, and they send them the source, and so, it appeared on github. I believe the initial released version was uploaded by kprasadvnsi.
Now, while I was happily debugging the CH32V103 with this release, it gave me troubles when attempting to debug a CH32V203. After some investigation I figured out, the problem was (hardware) breakpoints were not working. Instruction stepping the program from the reset vector would work, but that ain’t a useful way to debug.
On a second path, once I got my CH32V103 and one WCH-Link debugger, and I could debug my CH32V103 just fine, I went to order two more WCH-Links. Now, these new WCH-Links would not get detected by my OpenOCD version. One thing to note, for the working one, the blue led was off, while for the new ones, it is on. Upon some investigation, it seems this indicates wether the debugger is in ARM or RISCV mode. And the new debuggers were in ARM mode. This LED behaviour was explained in the product description of the WCH-LinkE in their official AliExpress store. The WCH-LinkE is a newer variant, which also supports debugging the CH32V0-series. While the product page is only in Chinese, a table with ✔ and ✗ doesn’t require translations.
Then, the next question, how to make it switch to RISCV mode? It seems there is a Windows program that can perform the switch. I’ve got a Raspberry Pi 4 running Windows 11, where I ran the said program. The program flashes a new firmware into the programmer, and there I was, with a firmware version 2.7. The old programmer had firmware version 2.3. Now it seems this new firmware version is not compatible any more with the OpenOCD version I was using. It was reporting firmware version 85 or something like that.
It seems, a while after the first request, someone requested the OpenOCD code again, and it got uploaded by hxu7wong. This version has in its readme openocd wchlink for WCH-Link firmware V2.4/V2.5. And it seems, this is the version that works with these new WCH-Link firmwares, furthermore, the breakpoints work on the CH32V203 and CH32V307.
Now, some notes to build the thing. It seems the code was written with less strict standard then the OpenOCD codebase, requiring the --disable-werror
to be passed to ./configure
Furthermore, there is something weird going on with the libjaylink submodule. I didn’t go into this and just disabled jlink support. I won’t use this build for debugging other targets anyways, so why bother? Anyhow, all of this results in the following to build it:
git clone https://github.com/xu7wong/openocd_wchlink
cd openocd_wchlink
./configure --disable-jlink --enable-wlink --disable-werror
make