WCH $0.10 USD RISC-V MCU

[brucehoult]

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

Yes you do. But all chips start up in M mode. Many microcontrollers don't have anything else.

Are you running under some RTOS?

[ataradov]

This document confirms that they are using a proprietary protocol and for details send to "WCH Debug Protocol Manual", which I can't find anywhere.

I also though that they licensed the cores, but it looks like they designed them.

[brucehoult]

Code: [Select]

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


Code: [Select]

misa 40800014
MXL  01 XLEN=32
res   0000
ext   00 1000 0000 0000 0000 0001 0100
      ZY XWVU TSRQ PONM LKJI HGFE DCBA

RV32EC (as expected) plus some non-standard Xtensions.

mvendorid=0 should mean it's a non-commercial core, listed at  https://github.com/riscv/riscv-isa-manual/blob/master/marchid.md But clearly not.

I don't know how to decode those marchid and mimpid :-( Google doesn't help.

[tim_]

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

Yes you do. But all chips start up in M mode. Many microcontrollers don't have anything else.

Are you running under some RTOS?

No, I am using the bare bones code that Mounriver is generating for startup (Basically initializing clock generator and UART).
When I try to execute the CSSR instruction, the controller hangs for the V203, while everything is executed on the V003. I am assuming that some kind of exception is generated, but have not looked further into it.

[tim_]

I don't know how to decode those marchid and mimpid :-( Google doesn't help.

Its explained in Chapter 8 of the processor manual:

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

The CH32V003 seems to have a "2" as a SerialID for the processer core, instead of a "4". The mvendorid register is appearently not implemented, but instead the vendorid is encoded as part of mimpid and marchid.

[GromBeestje]

For  the CH32V203 I've got

Code: [Select]

misa:      0x40901105
mvendorid: 0x0
marchid:   0xdc68d882
mimpid:    0xdc688001

It seems, when trying to debug, breakpoints are broken.

I am using are regular Eclipse with embedded extentions. I used the register view to obtain these values.

[GromBeestje]

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

Yes you do. But all chips start up in M mode. Many microcontrollers don't have anything else.

Are you running under some RTOS?

Note the default WCH startup files leave M mode before going to main, for example, see
https://github.com/openwch/ch32v307/blob/a1a924b5c9a0e54401a5e96324f0fbd48c643665/EVT/EXAM/SRC/Startup/startup_ch32v30x_D8.S#L365

I suggest an alternative startup file.
I've been working on a startup file and linker scripts that make it possible to use a GD32VF103 and CH32V103 with the same binary.
https://github.com/a-v-s/libhalglue/blob/rv32f103/compat/rv32f103/rv32f103.S

[brucehoult]

Note the default WCH startup files leave M mode before going to main, for example, see
https://github.com/openwch/ch32v307/blob/a1a924b5c9a0e54401a5e96324f0fbd48c643665/EVT/EXAM/SRC/Startup/startup_ch32v30x_D8.S#L365

Owww!  More precisely: in the act of jumping to main!  So contrary to the C spec there is no return from main. In a microcontroller environment I'd usually expect a return from main to at least lead to an infinite loop in _start.

I don't see where PMP is set up. Maybe in SystemInit.

Is an ECALL handler provided (and what does it support?), or can you provide your own and do anything you want in it?

[SiliconWizard]

That's interesting. Do those chips support all privilege levels? Which does it switch to before calling main? User?
Doesn't this cause problems for accessing peripherals? Do they switch to M when entering an interrupt? What else?

[brucehoult]

That's interesting. Do those chips support all privilege levels? Which does it switch to before calling main? User?

That depends on what is in the MPP field (bits 12:11, so mask 0x1800) of mstatus when the mret is executed to jump to whatever is in mepc (address of main)

Code: [Select]

    /* Enable floating point and interrupt */
    li t0, 0x6088
    csrs mstatus, t0

So that doesn't touch MPP. Maybe it's set up in SystemInit. Or maybe it's relying on MPP (and others) being set to 0s at reset.

Incidentally, it's a bit dangerous to enable interrupts before loading _vector_base into mtvec!

Doesn't this cause problems for accessing peripherals?

My thoughts exactly!  Depends on what is set into the PMP registers. Do they protect the peripherals I/O memory range from U? I don't know: PMP isn't set up in this file.

Do they switch to M when entering an interrupt?

By default, yes, but you can, if supported by the core, delegate individual exception vectors to U (or S, if implemented) mode. Thet requires setting up the utvec to point to user mode trap handlers, which we don't see here, and also medeleg and/or mideleg CSRs, which we also don't see set up here.

[GromBeestje]

Thanks to @tim_ I see they now published an English version of their V4 core manual.
Looking at chapter 7, I see it says

Note: Hardware breakpoints are only supported by V4C and V4F microprocessors.

That explains the problems I am seeing with the CH32V203, as it is a V4B core.

I am still waiting for my CH32V003 board to be delivered. I'm wondering if it supports breakpoints or not.

[tim_]

Has anybody been able to find information about the bootloader? According the the datasheet it resides in a flash memory block at 0x1fff f000. There is definitely code there, but no documentation can be found anywhere.

Code: [Select]

1ffff000:   j       0x1ffff736
1ffff004:   unimp   
1ffff006:   unimp   
1ffff008:   addi    sp,sp,-12
1ffff00a:   sw      s1,0(sp)
1ffff00c:   sw      s0,4(sp)
1ffff00e:   sw      ra,8(sp)
1ffff010:   jr      t0
1ffff012:   lw      s1,0(sp)
1ffff014:   lw      s0,4(sp)
1ffff016:   lw      ra,8(sp)
1ffff018:   addi    sp,sp,12
1ffff01a:   ret     
1ffff01c:   lui     a3,0x45670
1ffff020:   lui     a5,0x40022
1ffff024:   addi    a3,a3,291 # 0x45670123
1ffff028:   lui     a4,0xcdef9

There are also a couple of other features that lack proper documentation, like the OPAMP, but at least there are code examples for it.

[brucehoult]

The code at 1ffff008 and 1ffff012 makes a handy little function prolog and epilog that saves the return address and two callee-save registers. Let's call them save_2 and restore_2.

So you can write functions like this:

Code: [Select]

foo:
    jal t0,save_2
    // go ahead and use s0 and s1 as you wish, as well as the a and t registers.
    j restore_2

If foo is within ±4 KB of restore_2 then the j is a 2-byte instruction, but jal with t0 as the link register is always going to be a 4-byte instruction (with ±1 MB range).

[tim_]

The code at 1ffff008 and 1ffff012 makes a handy little function prolog and epilog that saves the return address and two callee-save registers. Let's call them save_2 and restore_2.

Indeed, its also part of the C library that is linked to every program:

Code: [Select]

__riscv_save_2:
000000a0:   addi    sp,sp,-12
000000a2:   sw      s1,0(sp)
000000a4:   sw      s0,4(sp)
000000a6:   sw      ra,8(sp)
000000a8:   jr      t0
          __riscv_restore_2:
000000aa:   lw      s1,0(sp)
000000ac:   lw      s0,4(sp)
000000ae:   lw      ra,8(sp)
000000b0:   addi    sp,sp,12
000000b2:   ret 


[josuah]

Here is the ongoing discussion (25 days ago) about reversing the debug protocol... straight on the official WCH repo's issues! 
They do not seem to mind, and take part in the discussion.

https://github.com/openwch/ch32v003/issues/3

Excerpts from it:

Apparently Mounriver has released the protocol. https://github.com/kprasadvnsi/riscv-openocd-wch
But this is not in a form where it can be used by a host CPU. Additional work is needed to extract out a minimal flash programming library.

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

[DavidAlfa]

(...) then I remembered I already had some low cost CM0 in my starsh (HK32F030 etc) that I never got around testing due to absence of useful documentation (...)

Do you still have them?
I forgot this and bought 25 for testing
If you have a J-Link (A BluePill can also be "converted" into a J-Link OB, PM me for details), it would be nice if you could take few minutes to install STM32 CubeIDE and load this project, should compile and run straight away, no lenghty setup required!

[josuah]

It looks like WCH started selling the bare chips in limited supplies: https://www.aliexpress.com/item/1005005036714708.html

Packs of 50 in 3 packages options:

- 50Pcs CH32V003J4M6 (SOP8) ~0.12 USD per chip, 6 packs left
- 50Pcs CH32V003F4P6 (TSSOP20) ~0.18 USD per chip, 6 packs left
- 50Pcs CH32V003F4U6 (QFN20) ~0.17 USD per chip, 9 packs left

[Sacodepatatas]

Currently there is no pack left for the CH32V003F4P6 package. Anyhow, considering one pack purchase, shipping cost and taxes applied to my country increase the price to 0.32€ per chip. Still good price though.

[DavidAlfa]

Yeah, the shipping cost is almost the same as the 50x chips!
So at the end it's 16€ for 50, like you say, 0.32€/chip.

Anyways, what happened? They made a mcu 2 years ago and it's already EOL?
Selling few packs at Aliexpress? Who is going to buy that else than hobbists?

[ali_asadzadeh]

They are responsive, I have emailed them directly and they would sell in any QTY that you want, I have get 1200Units of CH32V003 from them directly.

[DavidAlfa]

Why aren't they selling them at lcsc? They would ship zillions.

[JPortici]

These microcontrollers always leave me unimpressed. Yes it's cheap, but so is a PIC12/16 (or chinese clone of) with the same very basic set of peripherals and pinout. I guess it makes sense if you already have a development ecosystem built around the manufacturer's parts and peripherals, which is the reason why i still grab a PIC12/16 when i need a generic part with basic functionality

I guess i don't see the fuss over it. I consider these to be the same as the padauks. Yeah the core is more powerful but who cares, you don't really need to do much

[DavidAlfa]

Would you put a $5 mcu on a led flasher board? Or the cheapest thing that does the job? "A cheap PIC12, of course".
What if the cheapest ARM/RISC-V thing is still cheaper any PIC while several times faster?
DMA, nice timers, 32-bit processing, 48MHz...
It might not be a 400MHz Cortex-M33, but I wouldn't call it a PIC12 either! It's a great device for a lot of projects.

The HK32F030 doesn't have DMA, but has more ram, eeprom, better timers and other interesting peripherals.

[SiliconWizard]

But OTOH as said in other threads, if you're a western company designing such ultra-low-cost boards, you're barking up the wrong tree and deluded anyway.

Those chips are great for... asian companies that can actually leverage them, and for the sheer curiosity otherwise. Just my 2 cents. I have little doubt westerners will keep looking for cheapass MCUs because, you know, they are cheap.

[DavidAlfa]

You have libraries, documentation, toolchains and the interfacing is almost identical to other arm devices, so development will pretty straighforward.
And while most companies are having a real hard time at sourcing parts, where you might get the stm32 for 40 cents or $2 in 6 months, why not?
Buy  a few, test them, if doing nice then buy 10K and have stock until you get old.
If you have doubts about the future, put your mcu in a small secondary pcb with castellated holes, so retargetting isn't too dramatic.