ch32v307, risc-v minicore with ethernet

[SiliconWizard]

FYI, llvm meeting liked the prestacked annotation. Here is the more formal version of the proposal for wider review: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/53

Great, would like to see it in GCC as well.

Speaking of GCC, we talked about workarounds using mainline GCC, but what's the current state with the specific patches that WCH have included? Have they finally released those patches?
(If so I'll gladly try building GCC with these patches.)

[brucehoult]

FYI, llvm meeting liked the prestacked annotation. Here is the more formal version of the proposal for wider review: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/53

Great, would like to see it in GCC as well.

Speaking of GCC, we talked about workarounds using mainline GCC, but what's the current state with the specific patches that WCH have included? Have they finally released those patches?
(If so I'll gladly try building GCC with these patches.)

Note that WCH's own fast interrupt annotation implementation has the same restriction of not supporting interrupt routines that use FP.  It really just makes a standard C function that uses mret instead of ret. Their hardware with FPU doesn't have shadow registers for the caller-save FP registers, and so no one saves them.

__attribute__((interrupt, prestacked=....)) will solve that.

[SiliconWizard]

OK then. No need to bother if that's all they did.
Is the prestacked attribute planned for GCC too?

[SiliconWizard]

I've received my dev boards and managed to write my first test program using mainline GCC and a makefile.
This MCU has a few oddities.

For instance, it actually has 128 KiB of RAM, not 64. And it can be configured from 32 KiB RAM to 128 KiB with option bytes. The remaining RAM is used for improving Flash access, but they don't document clearly how they do that, and just finding out about it takes a while. The "base" config is 64 KiB RAM/256 KiB Flash, but you can choose from 32/288 to 128/192. Cool I guess, but odd and not clearly documented. Weirdly enough, the demo program that comes with their SDK (github) comes with a linker script that's set up for the 32/288 config. But there are comments inside it.

Other oddities, in no particular order:
- It has a CRC hardware module, but the polynomial is fixed.
- Not quite "odd", but the SPI has a max freq of 36 MHz. Not fantastic.
- There is no QSPI. A bit annoying. It has SDIO though. Up to 48 MHz.

Other than that, I bought "third-party" boards (not the WCH dev kit that comes with a WCH Link programmer) that do not come with a WCH Link. I was meaning to use OpenOCD eventually, but start using the USB bootloader (wch isp) - there's a Windows tool provided for it, and a couple third-party command-line tools have been made for other platforms. From my 2 boards, only 1 of them works properly with the USB bootloader. I haven't figured out why yet. Both can be accessed, but one of them behaves erratically when in the bootloader and can't be flashed this way, while the other works plenty fine for that. I can't tell if they could have a different silicon revision of the MCU.

Speaking of silicon revision, I could not find any errata on WCH's web site. That is also quite odd. I have a hard time believing the chip is 100% error-free.

Regarding OpenOCD, I haven't tried yet. I was kinda expecting that one could use any SWD adapter, as long as we compiled OpenOCD with the support for the WCH Flash functions. But some stuff I've read seems to indicate that only a WCH Link adapter can work. Is this not SWD? I thought OpenOCD was really using only the low-level parts of each protocol for the adapters ("interfaces") and assumed that a SWD adapter should work here. But I don't know. If anyone has more info on that - would be great not to be strictly stuck with WCH adapters. Happy to hear about your experience if you have already used OpenOCD with these MCUs.

[brucehoult]

It's a Single Wire Debug protocol, but it's not Arm's SWD.

WCH Link is cheap enough -- it's included in a $5 kit with CH32V003 dev board and five bare chips -- that it's surely not worth wasting time trying to bodge up something else?

Nevertheless, someone has programmed a Pi Pico to act as a WCH Link

https://www.eevblog.com/forum/microcontrollers/flash-and-debug-a-ch32v003-with-only-a-pico-gdb/

[SiliconWizard]

It's obviously not a matter of cost. I don't like haviing no choice for the programming tools and being tied to proprietary tools. On top of that, the official WCH Link is pretty meh, I'm not even sure it does level shifting (does it though?)

There have been attempts at reverse-engineering the protocol, like:
https://github.com/fxsheep/openocd_wchlink-rv/wiki/WCH-RVSWD-protocol
https://perigoso.github.io/rins/rvswd/index.html

But with missing parts. I'll have a look at https://github.com/aappleby/PicoRVD to see how far they've gone.

The QingKeV4 processor manual mentions "Different from the standard JTAG interface defined by RISC-V, QingKe V4 series microprocessor adopts 2-
wire serial debug interface and follows WCH debug interface protocol." and "Refer to WCH Debug Protocol Manual for specific debug interface protocols."

I couldn't find this debug protocol manual they mention, not even sure it is a public document. Would be nice if it was.

[brucehoult]

There is no longer a need to reverse-engineer the protocol, WCH published it a few months ago. No, I don't have the link to hand.

[SiliconWizard]

Precisely, where did they publish it?

The only thing I could find is this: https://github.com/openwch/ch32v003/blob/main/RISC-V%20QingKeV2%20Microprocessor%20Debug%20Manual.pdf

But that is the manual for the QingKeV2, not the QingKeV4 which the CH32V307 is. I have no clue how "similar" they are, I'll look at this doc and compare it with the reverse-engineering - possibly it is the same. Possibly there will be missing parts for the QingKeV4. Or not. We'll see. Edit: It's unfortunately not the same thing. The QingKeV2 has a single-wire debug interface (yes, without clock), hence the odd enconding of the 1's and 0's described  in its debug manual. The QingKeV4 has a 2-wire debug interface, like SWD. So, no luck there. There are probably similarities in the packets, but the low-level parts, including turn-around, are not known (to me) and still can't find the corresponding manual. Maybe I will eventually. The reverse-engineered material looks like (unsurprisingly) it misses the "big picture" and just interprets what has been seen with a logic analyzer in particular cases.

[bingo600]

I've received my dev boards and managed to write my first test program using mainline GCC and a makefile.

I have one in the drawer
Would you mind giving a link to the GCC download you used ?
And i would love to have the "test program & makefile" if possible , then i know i have something usable.


Well i downloaded this gcc
https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/

TIA
/Bingo

[brucehoult]

Well i downloaded this gcc
https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/

That's fine.

Most sensible OSes have had RISC-V toolchain packages for several years, which you can install using apt, yum, homebrew or whatever.

[bingo600]

Well i downloaded this gcc
https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/

That's fine.

Most sensible OSes have had RISC-V toolchain packages for several years, which you can install using apt, yum, homebrew or whatever.

Thnx 

I'm on linux (mint), and wasn't sure about the "guality" of the repos riscv-gcc

But i had no test program , and saw this one ... By Dan Drown ... I'we been looking for an ether lwip (non beta) test-program for a while.
https://github.com/ddrown/ch32v307-lwip/tree/main

I have built it yesterday, and have loaded it into the hw.
Haven't tried it out yet ...

I didn't even do a blinky, as my first riscv program ... 


Edit: I had to change one line in order to get it to compile


EDIT:
My "kit" came with a wchlink, set for ARM (swd) , not RISC-V , it's the cheap one wo. the buttons
Does anyone know how to change the "cheap" wchlink to RISC-V , without using MOUN River IDE (on linux) ??
I suppose it's uploading another fw when changing or
And i suppose i have to solder & connect the ISP jumper, if i want to change the fw on the wchlink ... correct ?
I'd like to get it going ..... wo. having to install a full IDE, if possible.


Luckily i also got a wchlink-e , that i could use for uploading to the board.

/Bingo

[SiliconWizard]

Would you mind giving a link to the GCC download you used ?

I build my own RISC-V GCC (from mainline 13.2 source code), but as Bruce said, it's available as a package on most Linux distros. There's also the xpack binaries, that you mentioned, that are supposed to be fine.
If you use Windows and can't build it yourself, the xpack binaries should work well. For some reason, the link you gave doesn't llst Windows binaries, but this one does:
https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/tag/v13.2.0-2/ (if anyone wants a Windows toolchain.)

And i would love to have the "test program & makefile" if possible , then i know i have something usable.

That's understandable, I'm often "embarassed" when asked this though, as I tend to use a number of tools and code that I can't necessarily share as is, so making a "minimal" example with "no strings attached" would actually take some work for me. I may do that one of these days.

But I can give you the exact compiler/linker options and a working linker script (I just used WCH provided linker script to start and modified it to configure 256K Flash/ 64K RAM, as it's the default config for the CH32V307 (that can be changed with option bytes) and that is not what they have put in their example linker script.

GCC compiler options (CFLAGS) (you can of course add your optimization, warning options, etc):

Code: [Select]

-mabi=ilp32f -march=rv32imafc -ffunction-sections -fdata-sections -msmall-data-limit=8 -mno-save-restore -fmessage-length=0

Linker options (LFLAGS):

Code: [Select]

-nostartfiles --specs=nosys.specs --specs=nano.specs \
  -Wl,-T"$(LINKER_SCRIPT)",-Map=$(MAPFILE),-o"$(TARGETELF)",--print-memory-usage \
  -Wl,--gc-sections

Linker script: you can take the "Link.ld" file that is provided in their SDK and just change the memory settings to:

Code: [Select]

FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K

The WCH SDK is there: https://github.com/openwch/ch32v307

[brucehoult]

EDIT:
My "kit" came with a wchlink, set for ARM (swd) , not RISC-V , it's the cheap one wo. the buttons
Does anyone know how to change the "cheap" wchlink to RISC-V , without using MOUN River IDE (on linux) ??
I suppose it's uploading another fw when changing or

You use a fork of OpenOCD that knows the WCH protocol.

https://github.com/openwch/openocd_wch

No IDE required. Just regular gcc and OpenOCD and WCHLink (or microcontroller such as Pi Pico programmed to emulate one, as pointed to up-thread)

[bingo600]

EDIT:
My "kit" came with a wchlink, set for ARM (swd) , not RISC-V , it's the cheap one wo. the buttons
Does anyone know how to change the "cheap" wchlink to RISC-V , without using MOUN River IDE (on linux) ??
I suppose it's uploading another fw when changing or

You use a fork of OpenOCD that knows the WCH protocol.

https://github.com/openwch/openocd_wch

No IDE required. Just regular gcc and OpenOCD and WCHLink (or microcontroller such as Pi Pico programmed to emulate one, as pointed to up-thread)

Right now it seems like the "Cheap" wchlink is identifying as (pid) : 8011 (arm debugger) , and need to be set to (pid) 8010  (and turn off the blue led)
I think that's a reprogram of the wchlink ... I was just hoping to avoid installing Mounriver to do the sw "upgrade"

 

[SiliconWizard]

I don't know what exact "cheap wchlink" you are using, but I know that the official one can be switched from ARM SWD to RVSWD and back by just pressing a switch on it. Read the manual. I'd be surprised if there was a clone of that cheap programmmer that didn't implement exactly the same thing.

[SiliconWizard]

As a follow-up, everything I've tried so far appears to work as documented, so that's a rather good thing. The documentation is not the greatest, but certainly rather good, even compared to major western vendors (and compared to most other chinese vendors I've run into). The English is even rather good overall. So kudos to WCH for that.

I haven't tested the USB controllers yet. I intend to test with TinyUSB (which supports the CH32V307), which I'm used to, and see how it goes.

The lack of QSPI is a bit of a bummer, but the FSMC looks quite flexible, and I'm wondering whether it's not possible to implement QSPI using it, as it supports not just asynchronous, but also synchronous transfers.
The data widths it supports are 8- and 16-bit only as far as I can tell, but it may be possible to maybe use it with just 4 data bits? Something to investigate. That would probably require some post-processing to reconstruct data words though, so may not be worth it.

There is a digital video port (DVP), that should be usable for other purposes.

Regarding the FPU, my (for now) limited testing seems to show that performance is not fantastic. I haven't done proper benchmarking, but I'd say, roughly, that typical add and multiply operations take around 10 cycles each at least. It's still several times faster than software emulation, but it's not eons faster.

To add to the list of oddities, the RTC peripheral only contains a 32-bit counter with programmable prescaler (and an alarm register and programmable events), but no date/time registers, so to implement date and time using it, you have to implement it all yourself using just a 32-bit counter. They provide example code for that though in their SDK (in the EVT/EXAM/RTC subdirectory).

As I said earlier, it doesn't look like they documented the 2-wire debug protocol for this chip - there is some reverse-engineering out there, incomplete. As far as I can tell, the only thing they published was the 1-wire protocol that is implemented in their lower-end RISC-V MCUs (CH32V003...), which is not the same thing. The WCH-Link adapter does support both.

Speaking of that, I'm wondering whether it is allowed to use SWD on anything else than an ARM core, legally speaking. I've found this very question on a couple other forums with no definitive answers to that. It would seem that a cautious answer would be "no". Which explains why non-ARM cores have to implement something else, even if SWD would be usable (and would leverage existing tools).

[ataradov]

The English is even rather good overall. So kudos to WCH for that.

A lot of their documentation is a verbatim copy from the ST documentation.

Speaking of that, I'm wondering whether it is allowed to use SWD on anything else than an ARM core, legally speaking.

You probably can, but it is tied to the ARM architecture, so you would not be able to use much past the physical packet format.

Which explains why non-ARM cores have to implement something else, even if SWD would be usable (and would leverage existing tools).

RISC-V defines its own debug interface. Unfortunately, that document tries to be very generic and allows for multiple transfer protocols (pins, USB, Ethernet) and explicitly leaves the details up to the implementation. They should have defined at least the standard GPIO-based one. From what I've seen WCH SWD is a wrapper over that standard debug interface and internally the debug subsystem is as described in the spec.

[HwAoRrDk]

A lot of their documentation is a verbatim copy from the ST documentation.

Well, sort of. It says the same things, but in a different way. I don't find the English to be great, just adequately understandable. It's as if perhaps they originally took the ST documentation, translated it to Chinese, then used that as a basis to translate to English.

(Although, that's just my experience with the  '003 docs - I haven't looked at those for the '307 much.)

[ataradov]

Well, sort of. It says the same things, but in a different way.

They moved the sentences around, but there are a lot of them that are just copy

ST: "When the transmit enable bit (TE) is set, the data in the transmit shift register is output on the TX pin and the corresponding clock pulses are output on the CK pin."
WCH: "When TE (transmission enable bit) is set, the data in the transmitter shift register will be outputted on the TX pin, and the clock will be outputted on the CK pin."

This is like you can copy my homework, just don't make it obvious.

They are gradually deviating from the original, but you can still see it all over the place.

And all the figures are also lifted directly from ST.

And when I was working with their ARM chips, having original ST documentation came in handy sometimes, since them moving thing around sometimes makes it worse.

[SiliconWizard]

Ha, I didn't go as far as doing some text analysis on the docs and have no prior experience with WCH docs in general. After checking, yes it appears that a good chunk of it (at least for the peripherals that are similar to ST ones) is very, uh, close to ST text. And sure, the peripherals themselves have been heavily "inspired" by ST as well (although they're not quite equivalent - the similarity is only on the surface, so while the peripherals will look familiar, do not expect strict equivalence).

But at least, the docs are understandable and implementation appears to match the docs (so far), so that's at least something. That's far from being always the case.

And yes, to be precise, I'm only talking about the CH32V30x here. Can't say anything about the rest of their offering.

One thing I'll test is I/O speed. As I mentioned, the DS states that SPI clock is 36 MHz max, but the RM says that it can be up to half of the peripheral clock, which itself can be up to 144 MHz. So, not sure what's up with that. That should be 72 MHz. Or maybe the 36 MHz max is for the slave mode only (which would require at least 4 clock cycles per bit, which isn't completely unusual for a SPI slave implementation). But the DS isn't clear about that, nor the RM. I don't know if they have maybe not characterized their SPI implementation above 36 MHz. Or if they just put a figure here taken from another DS.

[ataradov]

1/2 of the peripheral clock is the logical limit, you physically can't set anything faster. 36 MHz is the pad bandwidth limit. Both conditions are correct and must be met at the same time.

[SiliconWizard]

No, it's not the pad limit. (And 36 MHz would be pretty unimpressive.) The GPIOs are given for up to 50 MHz, the SD interface to 48 MHz, and the FSMC up to HCLK/2 with no max for HCLK (other than 144 MHz), so that would be 72 MHz.
So apart from the Fmax of the SPI peripheral itself (which doesn't look more complex than SD or FSMC to me), I see no particular reason for this limit. I'll be testing it to see what we get.

[bingo600]

I don't know what exact "cheap wchlink" you are using, but I know that the official one can be switched from ARM SWD to RVSWD and back by just pressing a switch on it. Read the manual. I'd be surprised if there was a clone of that cheap programmmer that didn't implement exactly the same thing.

This one (wchlink R1-1v1) wo. buttons, came with the 32v307 kit
https://www.wch-ic.com/products/WCH-Link.html

And "luckily" got  a wchlink-e (R0-1v3 w. buttons), when i bought a kit with the small 20-pin ssop's
They apparently require the wchlink-e


So i suppose the chinese "optimized" the R1-1v1 .. To be "cheaper" , and it supposedly needs to switch fw , via USB load. Not buttons (cheaper mcu)
I'll try to find a WIN PC , and run the WCH-LinkUtility , as it seems to be capable of switching fw, on the wchlink.
Then i can use that one for the 307' board.

Strange it came w. the 307 kit , but was default set for DAP not RV
Well .... Seams like it's 2.x$ vs 4.x$ for the E (on ali)


/Bingo

[SiliconWizard]

So I tested SPI @72 MHz on the CH32V307. It works. Winner winner chicken dinner, as Dave would say.

I looked at the signals on a scope, they appeared to be decent at this frequency. It could probably be fine up to 100 MHz or so. (But that would require "overclocking" the APB to 200 MHz, which is going to be another matter. I'm wondering how far we can overclock the core to begin with, so that'll be a future test.)

Then I set up a loopback test (connecting MOSI and MISO) for "long-term" reliability - it would light up a LED at the first error) and it runs flawlessly. Even with just a 20 cm Dupont wire that's not even properly soldered.

When reading the RM, I noticed that there was a register (that they otherwise don't talk about in the SPI description part) called "SPI High-speed Control Register" (SPIx_HSCR). There is a bit that can enable read in "high-speed mode".
It says:

Read enable in SPI high-speed mode (CLK is more than
or equal to 36MHz). This mode is valid only when clock
is divided by 2 (BR in CTLR1 = 000).

So that would suggest that SPI at > 36 MHz is possible, with this bit set. I'm not sure what exactly it does under the hood. There's no further documentation. Looking for it in the examples provided with their SDK, there's a couple occurences of it that are commented out (why? who knows, maybe this was just meant as a with/without test). Who knows why they didn't further document it - did they just forget to, or have they identified potential issues? Would be cool to have feedback from WCH about it.

My setup is: Sys clock and both APBs @144 MHz, SPI2 with the minimum prescaler (2), SCK and MOSI pins with max drive strength and the HSRXEN bit set in the SPI2_HSCR register. Note that I'm using SPI in master mode here, so I don't know if this would work in slave mode at this frequency.

[brucehoult]

Would be cool to have feedback from WCH about it.

Hit up @patrick_riscv or @wch_tech on Twitter.