WCH $0.10 USD RISC-V MCU

[josuah]

I've got to experiment with the boards today. The protocol is most definitely not a standard ARM DAP even on parts with two line interface, they just picked the signal names to match ARM counterparts.

Too bad! I thought ARM DAP wad ARM-only, but after all why would it be...

If every vendor comes up with their own debugging and programming interfaces, it would be a huge nightmare. Especially if those vendors don't bother documenting the protocol and their tools suck so much.

Based on your other comment, this is what happened with RISC-V by often picking JTAG instead of SWD?

Also, their software definitely tries to phone home. I ran it in an isolated VM not connected to the internet and some operations take suspiciously long time. It can be checking for updates and stuff, but still, be careful.

Spooky! Is this the tool you refer?
https://www.wch.cn/downloads/WCHISPTool_Setup_exe.html

[brucehoult]

At this time, I'm not all that interested to reverse engineering this.

Others have it working no problems, using the information at the links I have provided.

[ataradov]

Too bad! I thought ARM DAP wad ARM-only, but after all why would it be...

Legally there may be issues, I'm not sure what part of it must be licensed. There would still need to be changes to accommodate RV, but using the basic transport should be possible. After all, they copied NVIC, SysTick and other stuff like this.

Based on your other comment, this is what happened with RISC-V by often picking JTAG instead of SWD?

Compared to this, JTAG would be better. It would be great if someone involved with RISC-V cared about MCUs and standardized 1-2 pin count interface and more importantly, an actual debug subsystem. But they don't care, not even remotely.

And ultimately, whatever the protocol/interface it, it has to be documented. JTAG would be just as useless without documentation.

Spooky! Is this the tool you refer?

Yes. I think it also tries to load some UI elements from the internet. I'm not sure, but the UI looks broken without internet connection.

And this tool did not find WCH-LinkE in the USB mode, just the UART.

There is another tool they supply that looks much better and at least seems to be fast enough without internet connection. This tool actually found the programmer and that's what I used to look at the "SWD" interface.

Here is the more useful tool that actually worked for me with the real programmer mode, and not just a UART bootloader - https://www.wch.cn/downloads/WCH-LinkUtility_ZIP.html

[ataradov]

Others have it working no problems, using the information at the links I have provided.

Vendor tools work. But I don't want to use closed source Win-only tools that phone home.

And no, that Linux command line tool is not useful without the GUI because the actual config is taken from the INI file that is saved by the GUI tool. So, you have to run it at least once.

[GromBeestje]

I bought a WCH Link From AliExpress.
I have been able to program and debug a CH32V103 using OpenOCD built from the source they've released last year.
However, using the same OpenOCD, it doesn't seem to be able to debug CH32V203 successfully. It seems to flash though.


And regarding the debugging interface. I understand some vendors don't want to use JTAG for the number of pins required. And if using standard SWD is legally impossible, what about using cJTAG?

[ataradov]

cJTAG would work too. But ARM ecosystem is so much more than just the interface. And that's what fundamentally missing here.

With SWD and a standard DAP behind it, you can connect to any unknown device, read standardized identification ROM tables and know what debug components and capabilities are supported by the device. So, debuggers don't need to be told what target is attached to the interface, they can just connect and start working.

The physical transfer protocol is irrelevant, it just has to be something common. But the CoreSight system of debug components that ARM designed has no equivalent anywhere else, and that should be the goal of any open standardization effort.

I my case the board with CH32V203 that I've got this time did not work with the vendor tool, but the older board I already had with CH32V103 did work. I'm not sure why, it is possible that I killed my board with other experiments.

[GromBeestje]

How much is in the RICSV debugging specifications?
I was under the impression that once the physical layer is implemented the debugging is specified.

For example, when I consider a GD32VF103 device, which uses standard JTAG,
J-Link Commander will connect to it when I only specify "RISC-V" as device type.

[ataradov]

I was not aware of any standards, but searching for "RISC-V debug: 0.13" from the log leads to this document https://riscv.org/wp-content/uploads/2019/03/riscv-debug-release.pdf

This is much closer to what is needed. The document seems to only define JTAG transport, but it seems to be extensible.

Now the question is which devices actually implement this, and which devices roll their own. There is a chance that WCH implement the same standard but over their own undocumented transport.

I guess I need to get GD32 device and play with it.

And now I also wonder if WCH interface is actually just cJTAG. I'll have a closer look at it.

[brucehoult]

How much is in the RICSV debugging specifications?
I was under the impression that once the physical layer is implemented the debugging is specified.

For example, when I consider a GD32VF103 device, which uses standard JTAG,
J-Link Commander will connect to it when I only specify "RISC-V" as device type.

Well, yes, it's all been specified for a number of years. Only the physical layer changes according to technology, packaging etc.

https://riscv.org/wp-content/uploads/2019/03/riscv-debug-release.pdf

And there is also now standardised low-overhead execution tracing too.

https://github.com/riscv-non-isa/riscv-trace-spec/releases/download/v2.0rc2/riscv-trace-spec.pdf

It's all referenced from here:

https://wiki.riscv.org/display/HOME/RISC-V+Technical+Specifications

Of course there is nothing to FORCE anyone to follow any given spec -- and designs older than a given spec logically can't anyway -- but there's a lot lower friction for people who do follow the standards rather than inventing something themselves.

Saying that no one even cares is kind of dumb. A lot of people care, but it's a lot of work catching up on 35 years of ecosystem in the still less than six years since the very first RISC-V silicon shipped to the general public.

https://abopen.com/news/hands-on-sifive-hifive1-risc-v-development-board/

[brucehoult]

Now the question is which devices actually implement this, and which devices roll their own. There is a chance that WCH implement the same standard but over their own undocumented transport.

Even the very first commercially-available RISC-V hardware, December 2016's FE-310, implemented a compatible subset of this spec. RATIFIED spec (in 2019), by the way, don't be fooled by the 0.13 version number.

https://static.dev.sifive.com/SiFive-E310-G000-manual-v1.0.1.pdf

I can't say no one has ever rolled their own, but if you want to be able to simply use OpenOCD or Segger J-Link or whatever that support this spec then why would you?

[ataradov]

Even the very first commercially-available RISC-V hardware, December 2016's FE-310, implemented a compatible subset of this spec.

For the JTAG, sure. But even at the time of writing that spec it should have been clear that interface requiring 4 wires would be limiting and outdated. And the fact that this spec does not define 2 wire transport is very bad because it is a clear requirement for modern devices.

So, as a vendor you have to pick to require a lot of pins or roll your own. And in the best case  scenario you will have cJTAG in the worst case something proprietary and hacked up OpenOCD distribution to support it..

[josuah]

I wonder why a 1-wire half duplex UART is not used more often, like the UPDI interface:

https://github.com/microchip-pic-avr-tools/pymcuprog#serial-port-updi-pyupdi

Code: [Select]

                        Vcc                     Vcc
 ┌─────────────────────┐ │                       │ ┌────────────────────┐
 │ USB-UART dongle     ├─┘    ┌──────────┐       └─┤  AVR device        │
 │                  TX ├──────┤    1k    ├────┬────┤ UPDI               │
 │                     │      └──────────┘    │    │                    │
 │                  RX ├──────────────────────┘    │                    │
 │                     ├──┐                     ┌──┤                    │
 └─────────────────────┘  │                     │  └────────────────────┘
                         GND                   GND

It uses the RESET pin, so does it count as 0.5 pin?

The need for an internal clock being turned on, or maybe the slow speed...

[ataradov]

Reliance on the clock is one big thing. Both JTAG and SWD are fully functional from the interface clock alone. And the whole DAP logic behind SWD is also clocked by the interface clock, so the core may be sleeping or locked, but the debug interface would remain functional and may assist in recovery.

I'm not sure about UPDI devices, but AVRs in general are notoriously bad in that respect. It is very easy to brick the device.

[brucehoult]

Even the very first commercially-available RISC-V hardware, December 2016's FE-310, implemented a compatible subset of this spec.

For the JTAG, sure. But even at the time of writing that spec it should have been clear that interface requiring 4 wires would be limiting and outdated. And the fact that this spec does not define 2 wire transport is very bad because it is a clear requirement for modern devices.

So, as a vendor you have to pick to require a lot of pins or roll your own. And in the best case  scenario you will have cJTAG in the worst case something proprietary and hacked up OpenOCD distribution to support it..

The spec talks in a number of places about alternative transport layers, and is designed to not prevent them. USB is explicitly mentioned. Is ARM's SWD physical layer license-free? I don't know.

The market, as always, will decide.

[ataradov]

The spec talks in a number of places about alternative transport layers, and is designed to not prevent them. USB is explicitly mentioned.

I've seen this, and it is good that there are provisions for this. But just saying that implementations may do something, but not explicitly defining it would lead to chaos.

Is ARM's SWD physical layer license-free? I don't know.

No idea, but it is not like SWD is a holy grail, it has issues. It is very much linked with ARM DAP implementation, so may not be useful for RISC-V as is anyway. But defining a new clear low pin count interface should be a priority, IMO. And it should not be too hard to do, given that the debug spec is inherently universal enough.

The market, as always, will decide.

That is true to some extent. But in many cases fails where inferior solutions win because purchasing decisions are not made by engineers. Engineers will have to deal with whatever they are given.

[PCB.Wiz]

I wonder why a 1-wire half duplex UART is not used more often, like the UPDI interface:

https://github.com/microchip-pic-avr-tools/pymcuprog#serial-port-updi-pyupdi

Code: [Select]

                        Vcc                     Vcc
 ┌─────────────────────┐ │                       │ ┌────────────────────┐
 │ USB-UART dongle     ├─┘    ┌──────────┐       └─┤  AVR device        │
 │                  TX ├──────┤    1k    ├────┬────┤ UPDI               │
 │                     │      └──────────┘    │    │                    │
 │                  RX ├──────────────────────┘    │                    │
 │                     ├──┐                     ┌──┤                    │
 └─────────────────────┘  │                     │  └────────────────────┘
                         GND                   GND

It uses the RESET pin, so does it count as 0.5 pin?

The need for an internal clock being turned on, or maybe the slow speed...

It's not just the clock turned on, it needs to be defined to close tolerances and not change, or debug will crash.
I guess someone could include a debug oscillator, calibrated and separate from the system oscillator, but has anyone actually done that ?

Speed is probably ok, as HS-USB Bridge parts can manage 12MBd from FTDI, or 9MBd from WCH in TSSOP20

[westfw]

[WCH] replied within hours to notify that the tools for this new MCU are available through their Aliexpress webstore.

Neat.   I didn't know they had a web store.
Anyway, I ordered the "combo" kit (a 003, a 203, and a programmerlink) on 9-Nov, and it was supposed to arrive by 7-Dec.
Instead, it arrive today (19-Nov)!  I'm not ready for it !

[GromBeestje]

Nice! I have an order for a CH32V003 board from Tindie in transit.  Hopefully it will arrive soon.  At the time I ordered that I didn't see any on AliExpress yet. When I search now, I get a result, but "When "Maker Go Store" doesn't sound like what the official WCH store would be called. So what is their store called?

[ataradov]

So what is their store called?

It is linked in the edit in the first post of this thread. It is called "WCH Official Store". And it is official, the stuff comes in packaging with WCH logos and stuff.

[tim_]

I experimented a little bit to investigate instruction timing on the CH32V003.

Using inline assembler in GCC is straightforward. I used the loop below for timing:

Code: [Select]


        SysTick->CNT = 0;
        asm volatile (
                "   li        %[ctr],1000             \n\t"
                "lop:                                 \n\t"
                "   nop                               \n\t"
                "   nop                               \n\t"
                "   c.addi   %[ctr],-1                \n\t"
                "   bnez     %[ctr],lop               \n\t"
                :   [ctr] "+r" (x)
        );
        cnt=SysTick->CNT;



The flash waitstates can be configured. At 24MHz core clock, operation at zero waitstates is possible. At 48MHz one waitstate has to be introduced, otherwise the core gets notably unstable.

- Instructions execute in one cycle, as expected

- A taken branch takes 3 cycles, a nontaken one takes 1. So I guess there is speculative instructions fetch and each taken branch requires a pipeline flush.

- An unconditional jump also takes 3 cycles.

- One flash memory access is able to fetch two 16 bit instructions at a time. So an additional waitstate will not increase the instruction execution timing of every compressed instruction.

- Other than 32 bit fetch, there does not seem to be any kind of cache.

-> Pretty straightforward implementation. 48 MHz core clock is of limited benefit, unless you execute from SRAM. Unfortunately the clock system is somewhat unflexible. It does not seem to be possible to use 48MHz clock for the periphery and 24 MHz for the core.

[brucehoult]

- A taken branch takes 3 cycles, a nontaken one takes 1. So I guess there is speculative instructions fetch and each taken branch requires a pipeline flush.

- An unconditional jump also takes 3 cycles.

That's just what you expect from any standard simple 5-stage pipeline that DOESN'T have any form of speculation or branch prediction.

Cortex M0 and M3 are similar, they just have shorter pipelines so taken branches add a cycle less.

In this part of the market predictable execution time is more important than raw speed.

[tim_]

The CH32V203 appears to be significantly faster than the CH32V003.

   - Taken branches take 2 cycles instead of 3.
   - It seems to have a caching mechanism that allows executing most instructions from flash in a single cycle even at 144Mhz clock speed. There seems to be some penalty when using too many 32 bit instructions. The V003, in contrast, requires a memory waitstate for clk>24Mhz and will therefore execute instructions in either 1.5 or 2 cycles, dependings on instruction length (16 or 32bit).
   - Of course, the ISA implementation in the V203 (RV32IMAC) is more complete than in the V003 (RV32EC).

[brucehoult]

Could you check the contents of the mvendorid (0xF11), marchid (0xF12), mimpid (0xF13), misa (0x301) CSRs?  I.e. CSRR dst, 0xF11 etc.

Note: CSRR is a pseudo-instruction that the assembler should recognise, but if not then it's CRSRS dst, csr, x0

[tim_]

Could you check the contents of the mvendorid (0xF11), marchid (0xF12), mimpid (0xF13), misa (0x301) CSRs?  I.e. CSRR dst, 0xF11 etc.

Note: CSRR is a pseudo-instruction that the assembler should recognise, but if not then it's CRSRS dst, csr, x0

On the CH32v003:

Code: [Select]

void printCSR(void)
{
    uint32_t tmp=0;

    asm volatile ("csrr    %0, misa": "=r" (tmp) );
    printf("misa:%X\n", tmp);

    asm volatile ("csrr    %0, mvendorid": "=r" (tmp) );
    printf("mvendorid:%X\n", tmp);

    asm volatile ("csrr    %0, marchid": "=r" (tmp) );
    printf("marchid:%X\n", tmp);

    asm volatile ("csrr    %0, mimpid": "=r" (tmp) );
    printf("mimpid:%X\n", tmp);
}

output:

Code: [Select]

misa:40800014
mvendorid:0
marchid:DC68D841
mimpid:DC688001

The code fails on V203 as I apparently have to enter machine provilege mode first.

[tim_]

The CH32V203 appears to be significantly faster than the CH32V003.

   - Taken branches take 2 cycles instead of 3.
   - It seems to have a caching mechanism that allows executing most instructions from flash in a single cycle even at 144Mhz clock speed. There seems to be some penalty when using too many 32 bit instructions. The V003, in contrast, requires a memory waitstate for clk>24Mhz and will therefore execute instructions in either 1.5 or 2 cycles, dependings on instruction length (16 or 32bit).
   - Of course, the ISA implementation in the V203 (RV32IMAC) is more complete than in the V003 (RV32EC).

I the mean time I noticed that there is a nice processor manual for the core used in the CH32V203 (QingKeV4):

http://www.wch-ic.com/downloads/QingKeV4%20Processor%20Manual_PDF.html

The core has a 3 stage pipeline and supports branch prediction. That explains why taken branches are one cycle faster than on the QingKeV2 core.