Electronics > Microcontrollers

Reflashing a bricked WCH-LinkE

(1/5) > >>

Noting the earlier discussion at https://www.eevblog.com/forum/microcontrollers/wch-$0-10-risc-v-mcu/msg4549094/#msg4549094

--- Quote ---A reverse inginering of WCH (ch32v) SWD protocol is made by @fxsheep here https://github.com/fxsheep/openocd_wchlink-rv/wiki/WCH-RVSWD-protocol
The flash algorithm for varios wch parts was found in @kprasadvnsi repo on https://github.com/kprasadvnsi/riscv-openocd-wch/blob/master/src/jtag/drivers/wlink.c#L110-L337
Maybe a new openocd with ch32v003 support is required but the MounRiver guys are receptive if you send an e-mail to support@mounriver.com
But this require a lot of work for obtain a full floss toolchain to work...

--- End quote ---

I've started a separate thread since this could end up being an FAQ.

I've got one of the WCH kits available via ALI which have a couple of evaluation boards, a WCH-LinkE programmer, and some additional chips, and have been carefully setting up MounRiver on Linux so that I understand its dependencies.

Following Dave's lead, I compiled GPIO_Toggle without significant problems ** . However when I went to Flash->Download it MounRiver told me that I needed to "update" the WCH-LinkE firmware from 2.8 to 2.7, and wouldn't cooperate unless I did. However what it actually wrote was the newly-compiled .hex file, so the programmer is now a brick (flashing a pretty blue LED, but a brick nonetheless).

How do I recover from this, and most importantly how do I prevent its happening to other people? Because right now I'm less than confident recommending this for a project I'm being asked about.


** Noting Dave's problem with the GPIO bit connected to the LED, on these evaluation boards it looks as though the two LEDs are taken to header pins which need to be jumpered to suitable port pins.

Take a look at the pages 13 and 14 of the WCH-Link(E) manual.

Thanks, I'll investigate. I might need to look very carefully at what version of MounRiver Studio I've got, in case the upgrade/downgrade/botch is something to do with that.

Is the transparent case on the WCH-LinkE glued/welded? I'm trying to decide whether to pry harder or get the Dremel out to drill holes over the buttons.

(Slightly later) So if I'm reading that correctly, "WCH-LinkUtility offline update (2-wire approach to offline update)" is applicable to a WCH-LinkE, i.e. I need a second programmer plus the WCH-Link software.


Yes, it seems that the only way of updating the firmware is through SWD, then a second WCH-LINKE would be needed (unless the SWD propietary protocol would be released soon as stated by Patrick Yang), because the 1-wire protocol has been minimalistic ported to ESP32 and STM32F042, if I recall right). I guess the CH32V305 in TSSOP-20 that is on the PCB doesn't let access to boot0 or boot1 pins, so the bootloader for DFU or maybe UART cannot be started. That's why the need of another WCH dongle for unbricking this one.

When I first got my WCH LinkE, it appeared to be bricked. It wouldn't enumerate on Linux.
However, it would enumerate on Windows, and using the Windows updater I updated the WCH LinkE and then it would enumerate on Linux. I'm not sure what versions they were at though.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod