Reflashing a bricked WCH-LinkE

[MarkMLl]

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

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...

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.

MarkMLl

** 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.

[Sacodepatatas]

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

[MarkMLl]

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.

MarkMLl

[Sacodepatatas]

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.

[GromBeestje]

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.

[MarkMLl]

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.

Thanks, I'll check and report back. When you say "wouldn't enumerate on Linux", were you looking for the serial device (e.g. /dev/ttyACM0) or were you looking at lsusb output and checking the /dev/bus/usb tree?


Slightly later: lsusb /does/ report a device, but the kernel doesn't know what to do with it.

Code: (plain) [Select]

Bus 002 Device 015: ID 4348:55e0 WinChipHead
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          255 Vendor Specific Class

[Mar20 07:34] usb 2-1.5: new full-speed USB device number 15 using ehci-pci
[  +0.108750] usb 2-1.5: New USB device found, idVendor=4348, idProduct=55e0, bcdDevice= 1.00
[  +0.000012] usb 2-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0

"Winchiphead CH341 Driver
    This driver is for the Winchiphead CH341 USB-RS232 Converter. This chip also implements
an IEEE 1284 parallel port, I2C and SPI, but that is not supported by the driver. The protocol
was analyzed from the behaviour of the Windows driver, no datasheet is available at present."

Unfortunately 4348:55e0 is not an ID that the Linux kernel knows about: the CH341 driver responds to 4348:5523. In the past I've tinkered a little with the CH341's I2C etc. capabilities https://github.com/MarkMLl/i2c-ch341-usb but I think that relies on the standard IDs.

I note that the part-decoded WCH-Link protocol is described as I2C-like, and when I have time I'll take a closer look at that and see what ID it expects: it might be that in combination with the project above the programmer could be reflashed with no additional hardware.

I've got a response from support@mounriver.com but so far they don't really seem to understand that their software can brick the programmer: they still think that the IDE should be able to upgrade the firmware, but while there's some slim possibility that libusb could do something with that device as it stands... without a module/driver that knows about that non-standard ID I don't think that will happen.

In any event, this gives some indication of how Windows might be able to recover: but I bet that it relies on a driver having been installed.

MarkMLl

[MarkMLl]

OK, sorted.

The key is that when MounRiver Studio wrote the wrong firmware to the WCH-LinkE programmer, it changed the vid:pid identifier so my udev rules file- which was only looking for the operational ID 1a86:8010- was no longer prepared to put it into the plugdev group.

If I use the slightly more complex file

Code: (shell) [Select]

# Remember to  udevadm control --reload  after any changes.

# Assume that the CDC serial device (typically /dev/ttyACM0) has already been
# assigned to root:dialout on account of its class.

# Operational WCH-LinkE:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="8010", ATTRS{product}=="WCH-Link", GROUP="plugdev", MODE="0660"

# This untested, and refers to the WCH-DAPLink
#
# SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="8012", ATTRS{product}=="WCH-Link", GROUP="plugdev", MODE="0660"

# WCH-LinkE recovery mode:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="4348", ATTRS{idProduct}=="55e0", ATTRS{bDeviceClass}=="ff", GROUP="plugdev", MODE="0660"

the recovery/reflash identifier will still be in the plugdev group, and the IDE will be able to flash the firmware version that it believes is appropriate into the programmer.

So provided that I have relaxed my security requirement slightly as above (or am prepared to throw caution to the wind and run MRS as root) their support desk's suggestion is appropriate:

        Hello, MRS will check whether the connected WCH-LinkE firmware version is consistent with the communication library version built into the current software. If it does not match, it will burn the WCH-LinkE firmware to the version built into MRS to enable normal communication. Based on the current device status, it is recommended that you download and install the latest MRS V1.84 version, select a built-in template program, and click the download button. WCH-LinkE will automatically upgrade to the corresponding V2.8 firmware version.

...subject possibly to a bit of replugging. I am now able to write the .hex file to the target, without screing the programmer, and am pleased to confirm that GPIO_Pin_0 is actually PD0 :-)

All above was with MounRiver Studio Community v1.30 on Debian Linux "Bookworm" x86_64. An update might have just been made available, but is not yet showing up on the main download page at least for Linux.

MarkMLl

[GromBeestje]

Thanks, I'll check and report back. When you say "wouldn't enumerate on Linux", were you looking for the serial device (e.g. /dev/ttyACM0) or were you looking at lsusb output and checking the /dev/bus/usb tree?

By the dmesg output. The enumeration process fails

Code: [Select]

[ 5892.539593] usb 2-6.2: new full-speed USB device number 46 using xhci_hcd
[ 5892.796254] usb 2-6.2: unable to read config index 0 descriptor/start: -32
[ 5892.796263] usb 2-6.2: chopping to 0 config(s)
[ 5892.796265] usb 2-6.2: can't read configurations, error -32
[ 5892.802068] usb 2-6-port2: unable to enumerate USB device


[MarkMLl]

That reminds me of something. When I was looking at the original Tang Nano FPGA board I found that it was unreliable unless plugged directly into a USB v1 hub: and that similarly had an onboard WCH microcontroller, which in that case was actually programmed with FTDI IDs.

So there's a possibility that some of these devices don't have very robust USB implementations, particularly when running in a fallback mode apparently implemented in the bootloader.

I'm still a little confused as to what was really happening in the current case. The water's slightly muddied by the fact that what I'm actually doing is exploring putting untrusted development tools into Docker containers, and since Docker's hotplug ability is limited there is a possibility that that contributed to the confusion.

And I don't know for certain whether MRS really had loaded the GPIO_Toggle demo code which was blinking the blue LED, or if it was running bootloader firmware: which their support said would turn on the blue LED with no mention of it flashing.

So there's the nagging question of whether (some of) these devices have USB support hardware, or firmware in the bootloader, which can be enabled without the involvement of the normal application code. I would hope that they could be answered by detailed study of the reference material.

MarkMLl

[Kenjutsu]

I am in a similar position as the OP. The difference is that I am on a M1 Mac and used wchisp - WCH ISP Tool in Rust to mistakenly upload firmware for a CH32V003 to my WeAct Studio WCHlink Debugger 

wchisp info can still see the WeAct board: Chip: CH549[0x4912] (Code Flash: 60KiB, Data EEPROM: 1KiB)

My question is where can I download the correct firmware to upload via wchisp back on the WeAct board?

Thank you!

[MarkMLl]

My question is where can I download the correct firmware to upload via wchisp back on the WeAct board?

The key phrase is "it will burn the WCH-LinkE firmware to the version built into MRS", i.e. there's a copy of the current firmware embedded in the MounRiver IDE with the capabilities expected by the IDE's loader, and the IDE can update the firmware provided that it sees (and recognises) the device.

While I'm very much in favour of expanding the number of supported programming languages, I'd caution that this is a special operation and might be best left to WCH's own code.

MarkMLl

[HwAoRrDk]

To reflash a bricked WCH-LinkE device, you will typically need to follow a specific procedure to restore the firmware or software on the device. Here are some general steps you can take:

...

Gee, thanks ChatGPT, that was most helpful. /s

[MarkMLl]

To reflash a bricked WCH-LinkE device, you will typically need to follow a specific procedure to restore the firmware or software on the device. Here are some general steps you can take:

Read the thread: it is done automatically by the IDE.

The thing that gave me problems initially was that I had not mapped all possible USB IDs through to Docker (and put them into Linux udev rules files etc.).

MarkMLl

[dquadros]

Just to document: the transparent case is not glued. You can pry it open with a screwdriver (and some care). Start at the connectors where there is a small space between the two parts.

Not sure how I bricked mine. WCH tools were asking to update it all the time, sometimes saying the update was ok, sometimes saying something went wrong. At some point the WCH-LinkE just stopped communicating. Currently waiting for a new one to try to burn the firmware again.

[dquadros]

Really confused about the WCH-LinkE. I tried my "bricked" device on two computers (one running Windows and the other Linux) and there was not sign of USB communication. After opening the case, I connected it to the Windows machine with the APP button pressed and it was recognized. Running the WCH-LinkUtility, it once again asked permission to update; after the update (and removing and plugging it again), the WCH-LinkE is working fine.

[MarkMLl]

Really confused about the WCH-LinkE. I tried my "bricked" device on two computers (one running Windows and the other Linux) and there was not sign of USB communication. After opening the case, I connected it to the Windows machine with the APP button pressed and it was recognized. Running the WCH-LinkUtility, it once again asked permission to update; after the update (and removing and plugging it again), the WCH-LinkE is working fine.

One thing that came out of my tinkering earlier in the year: ALWAYS look at the vid:pid pair that comes from the device, try to work out what it represents, and examine whether the udev rules can be improved.

At about the same time I did quite a lot of work configuring Docker for different development environments (typically either Eclipse or Arduino) and programmers. In almost all cases I was able to map the programmer through the Docker sandbox (or whatever you want to call it), but that typically required more security features to be disabled than I was really happy with.

MarkMLl

[mikeselectricstuff]

I'm having the same issue under Windows (7) - flashing blue LED after Mounriver attempts to update the WCH-link.
In addition,  Attempting to run WCHISPStudio from within Mounriver gives an error "The prcedure entry point CH375readEndP could not be located in the dynamic link library CH375DLL.DLL"

Any clues..?

Update - tried a WIN10 PC and still not able to run  WCHISPStudio due to lack of CH375DLL.DLL

[mikeselectricstuff]

OK running setup.exe within the WCHISPTOOL folder has dealt with the CH375DLL issue.

Running WCH-Linkutility ( in Extool\SWDtool ) seems to have updated it now, no longer getting flashing blue. Don't recall what I selected in this tool - I think it auto-detected.

I don't have the hardware to hand now but Mounriver now seems to think the wch-link version is correct so looks like this solved the issue

[MarkMLl]

Glad you've got that sorted. The one thing I would add is that I found their support approachable and competent when I had the problem described in OP: they appear to "have the right attitude" when it comes to breaking into the market.

MarkMLl

[ali_asadzadeh]

Does any one know what CH217K part do? my guess is that they are Power switches? Does anyone have their datasheet?

[eutectique]

Does any one know what CH217K part do? my guess is that they are Power switches? Does anyone have their datasheet?

The topmost link suggested by google leads here: https://nl.aliexpress.com/i/1005005392218373.html

Scroll a bit down to see the pictures of the datasheet.

[MarkMLl]

The topmost link suggested by google leads here: https://nl.aliexpress.com/i/1005005392218373.html

"USB port power switch with adjustable current limiting theshold [...] alarm open-drain output active-low".

Note two different pinnings with K and X suffix.

MarkMLl

[HwAoRrDk]

The resistor values they're using (150k and 300k) give a current limit of 400mA for 5V and 200mA for 3.3V.

On the older version 1.2 of the LinkE, they used to have 150k R_set resistors for both, but I guess they figured that was stupid because the SOT23 voltage regulator they're using for the 3.3V won't be rated for that anyway.