WCH RVSWD protocol

The following info is only guessed via sniffing using a logic analyzer. No further testing has been done yet!

Intro

RVSWD is the name of the proprietary two-wire debug interface on WCH's RISC-V MCU. Similar to ARM's SWD interface, RWSWD has two wires named SWDIO and SWCLK respectively, but the protocol is not compatible.

Basics

This protocol has some characteristics of I2C. Specifically:

• SWCLK and SWDIO are high when there's no transaction.
• SWDIO changing to low while SWCLK is high marks a START condition.
• SWDIO changing to high while SWCLK is high marks a STOP condition.
• SWDIO should change only when SWCLK is low during transaction.
• When SWCLK is high, a bit is interpreted as 1 if SWDIO is high, interpreted as 0 if SWDIO is low.

A transaction is always initiated by the host(WCH-Link). The protocol is point-to-point, thus there's no slave address. There's no ACK/NACK either.

Format

Type	START	Address	Data	Operation	Parity1	Address	Data	Status	Parity2	STOP
From	Host	Host	Host	Host	Host	Target	Target	Target	Target	Host
Length(bit)	-	7	32	2	1	7	32	2	1	-

Note:

1. All fields are MSB first.
2. Parity1 (Host) is odd parity of Address, Data and Operation field.
3. Parity2 (Target) is even parity of Address, Data and Status field.

As one can see, this protocol basically exposes(addr+data+op/status) the dmi (0x11) register of DTM (Debug Transport Module) in a typical JTAG implementation.

WCH-Link behavior

• When WCH-Link is booted into RISC-V mode, both SWDIO and SWCLK are first set high. The link then sends 100 ones (100 clocks with IO high), and a STOP condition(IO low, then clock high, then IO high). This is likely a wakeup sequence.
• When the host PC(OpenOCD) sends Read status command, WCH-Link will send some debug operations to the target autonomously to retrieve chip info. (I didn't look into it carefully. It basically consists of running some code via progbuf and probably reads some registers in the address space.)
• During normal operations, WCH-Link acts as a simple USB to DMI bridge, which fills Host fields above from DMI Read(Write) Request from PC, then sends DMI Read(Write) Response with data read from Target field (send by MCU) back to PC.