Underlying protocol error 0x55

[unwind]

I'm trying to flash a home-built little board holding a WCH32V203F8P6 using wlink to drive an (official, I think, but from AliExpress) WCH-LinkE probe. I've updated the firmware of the probe to v2.18 using wlink-iap.

However, any command involving the target fails, like this with flash:

$ make flash
sudo ~/tmp/wlink-linux-x64/wlink -v flash --enable-sdi-print --watch-serial ./init.bin
09:47:53 [DEBUG] (1) wlink::usb_device::libusb: Serial number: "07858F068CB7"
09:47:53 [INFO] Connected to WCH-Link v2.18(v38) (WCH-LinkE-CH32V305)
09:47:53 [DEBUG] (1) wlink::operations: retrying...
Error: WCH-Link underlying protocol error: 0x55 [
    0x81,
    0x55,
    0x01,
    0x02,
]

I kind of vaguely suspect that this is a problem with the probe's ability to drive the NRST reset output, since I have been investigating/fighting the issue for a while.

I was developing against the board for weeks, flashing probably hundreds of times, then one day it suddenly stopped working while I saw signs of some USB issue (the probe was connected to hub to which keyboard and mouse were also connected, and the keyboard powered down). I thought I had managed to short NRST and 3V3 in the debug cable/connector somehow, but I have checked the wiring many times now, yet it still happens on a brand new LinkE.

Manually holding the reset button on my board down and releasing just when running the command (modulo some timing) can make wlink get further, but I think the flashing procedure involves at least one more software-driven reset (it prints Reattach chip twice) and then it fails again at that point.

So, uh, I guess my question(s) boil down to:

1. Is failure to drive NRST consistent with the "underlying protocol error"?
2. Have anyone else experienced something similar, is the NRST output on the probes known to be very sensitive?
3. Any other ideas, please?

Thanks a lot for all your work, it's a great tool and I really enjoyed using it while it worked for me, and just want to get back into that groove. :|

Minor update: I tried upgrading the probe to the very latest firmware which I was not aware existed yesterday (v2.6, released 2025-10-20) but it behaves exactly the same. If I can locate some older release I might try downgrading, but I'm not very optimistic.

Another update: I finally got around to hooking the outputs of the probe up to a logic analyzer (no target, so my board is no longer connected at all) and tried a flash like above, got this:

So it's quite clear that the NRST line is not moving at all, while the data/clock lines work just fine. Bummer, I can't understand what I do wrong to so easily destroy the hardware. :(

Another update: I managed to find this page which has a download link for firmware v2.11 (v31) so I re-flashed, but there was on difference so I guess my only conclusion has to be that the pin driving the NRST output from the LinkE is busted. :|

[Christian-Prather]

I am experiencing this same error. I have a wlinkE 1.3 device (several actually all with same outcomes) and am getting

wlink status
16:22:46 [INFO] Connected to WCH-Link v2.15(v35) (WCH-LinkE-CH32V305)
Error: WCH-Link underlying protocol error: 0x55 [
    0x81,
    0x55,
    0x01,
    0x02,
]

This can also be recreated if the probe is not connected to the MCU which makes me think this is tied to the actual firmware on the wlink

[aq1018]

I think NRST is only used for very specific commands, which I don't exactly remember... The probe issues software reset command instead of toggling NRST pin. From my own experience it's either a connection issues or the chip is in a busy loop and the probe cannot attach.

Check a few things:

1. You have 3.3v, GND, SWDIO, SCLK hooked up. The V203 series uses 2 wires for debug.
2. Make sure connections are secure and tight.
3. Try to hold reset button if you have one and let go, or plug in the usb and immediately followed by issuing 'wlink erase'. The idea is to get wlink attach to the chip before it hits the busy loop.

Assuming there is some code that's busy looping, it might get you out of the situation.

P.s. wlink also has a handy command that can enable and disable 3V3/5V powers, use wlink help for more details, I can't remember off the top of my head... you could do disable power, enable power, erase in quick succession, might get better results than doing reset by hand.