ch32v307, risc-v minicore with ethernet

[PCB.Wiz]

Interesting family,  USB-HS in small TSSOP20 package is a first.

Has anyone with an Eval Board, tried their github CDC USB example ?

Curious what baud rates it can manage up to ? In simplex and in full loop-back echo ?

[hans]

You don't necessarily stream continuous data at full speed through USB 2.0. For example it has 2x I2S, so with the right firmware and audio class 2 drivers, it could be a 24 bit 192KHz USB-I2S bridge. Which is only 9mbit/s but it doesn't fit to USB 1.1 speeds.
It looks like a very capable chip. Does this RISC-V4F have execute in place capabilities for external flash?

Good point. There is a huge gap between 12Mbit and 480Mbit, and 100Mbit and 1000Mbit. tens of Mbit with flow control (USB, TCP) is plenty of data to manage for a MCU, but can be an useful application.
Especially on USB aspects you don't have to worry too much about "Denial Of Service" attacks, which on networks (even LAN) can be a problem.

I must correct my previous comment as well. The 2.64 Coremark/MHz shown in the link is just a random sample. Looking at the Makefile, there aren't that many optimization flags added to make it run just that bit faster (with an unrealistically large binary size). It may account for 10-20% extra gain, but compared to the Coremark scores databases with optimized builds would bring it a lot closer to a Cortex-m4, making it a decent mid-range MCU.

Yeah, a few thoughts:
- Not to sound offensive at all - sorry if it does sound so - but, I think many chinese companies have a "loose interaction" with intellectual property in general (in particular that of others), and fully respecting open-source/free software licenses is not necessarily one of their main concerns.
- There are companies that make their modified source fully and easily available, but it only very moderately helps anyone building/maintaining their own version. Microchip comes to mind.
- And yes, as newbrain just said, I guess the huge majority of users do not care anyway.

I think you first thought is a genuine truth I've been able to speak to some Chinese people/students over the years, and the impression I've got is that "innovation" has a different meaning than here in the west. Just look at the number of STM32F103 clones out there: afaik you almost need more than 2 hands to count them. There is no real incentive to make something unique, if you can also boost the economy by making it less dependent on the west. (Now these people may be biased since they are actively chasing opportunities to go abroad, and stay abroad and away from China if possible.)

Imagine all the time spent reverse engineering to make a functional equivalent clone at a RTL level, instead of making a HAL API compatible chip, or something unique that's simple to use and program. You can also see it very clearly in this device: the manual is shared with a STM clone, with RTL and naming conventions also straight copy-paste. It wins big in familiarity on that front.

Would I care? Yes, but no, but.. AFAIK STMicro isn't doing too bad, by having sold everything they got, I can see why people would go/need to use some "clone" or IP infringing product. However, what if STMicro would scale down their MCU branch, or go out of business, because nobody buys their stuff anymore? Then I would have a big problem with it. I wouldn't be amazed if they are pushing hard to have transports of clone chips into EU/US banned/actively enforced, including reels of bare chips but also finished devices. After all, you can't bring in a counterfeit Rolex from your holiday destination, so why would you be able to buy a counterfeit or IP infringing MCU.

On the other hand, we also openly discuss how to feature unlock a scope/etc. because we're of the opinion we already paid for the hardware, and it's MY hardware, that has the capability to do feature X. So what gives. As a hobbyist, if I can get my hands on silicon that can run code and toggle it's pins, then that's already alot to be happy about.

Concerning MCP XC compilers: it's sad to see the state of it. I honestly think that if MCP had better tools they would have been a lot more popular. However, if you compare it to Espressif, is that situation really that much different? I mean, do you also compile your ESP8266 or ESP32 binaries with WiFi support WITHOUT using ESP-IDF and just using mainline GCC?
My own answer to that question is yes: their situation is different. The low-hanging fruit answer is they don't charge for a "pro" compiler. But I think the more elaborate answer is that they have made tools that don't outright suck from an users perspective. It doesn't take 30sec to upload a 16K binary to a PIC32 chip. It doesn't loose USB connection to a PICKIT half of the time. The debugger firmware doesn't have a mind of it's own, etc.
 
Certainly it is possible to dive deeper into the tools and get something to work. For example, just the other day I was able to get code for PIC32s compiled and debugging code happily on MIPS GCC 11.3, GDB and OpenOCD over JTAG. It is possible, but I feel a bit ashamed it had costed me almost a full week of tinkering to get the settings in dialed right to get something that seems to work.. but can't be certain it's 100% crash free. But from my point currently, XC32 is not much more than mainline GCC, some crt0, header files and libraries, and finally commandline adjustments so you can type -mmcu=PIC32MX795F512H instead of -march=m4k -mtune=4kem, etc.

[DiTBho]

scanned

You scanned some manuals, while I own a couple of brand new DEC-terminals with their weird keyboards and paper manuals 

I paid them something like two cups of coffee, bran new still in their box, by a guy in Estonia who had no idea what to do with such weird things nowadays, and I don't like them either, to be honest I prefer my VT650 with its simple RS232 interface.

The VT650 talks on a serial port 9600bps-1S-8bit-1S-noparity, and it's back-compatible with everything: vt100, vt220, etc. You can attach it to a GNU/Linux box and use it as serial console, somehow similarly to what you could easily do with a laptop running Minicom, or Pico, but the termcap support is better and it also feels more appealing due to its retro-style.

Vim is a pleasure, Emacs not so much due to the weird keyboard, but Nano an Joe do rock!!!

It needs a special multi-function keyboard which is a common ps/2-type3 keyboard(1) but with some extra keys. Luckily I have one now. When I swapped one of my routers for the VT650 unfortunately the keyboard was missing, so I searched for it for two years and paid 90 euros on eBay. That bloody things are very rare and expensive.

Anyway, now it's fully working and I am enjoying it 

Back to the DEC-terminal, I don't want to use it, rather I want to replicate a part of the LAT functioning for a custom-made terminal, for which I am going to create my own LAT-like protocol, and it makes perfectly sense that above 80 milliseconds latency you will notice the sluggish character echo.

I have already built my terminal the way I described in my previous post, and noted it: above 80 milliseconds latency you feel the console is going bloody slow!

So it makes sense the 80 millisecond delay in LAT is a great trade-off idea to offload the network by sending fewer larger packets which also reduces interrupts at each system 

(1) common ps/2-PC-keyboards are type2

[ve7xen]

Received my board today. Tried to build the openocd fork that @newbrain kindly obtained from WCH. Building it was slightly...nonstandard, so leaving what I did here for posterity. I might submit a PR to newbrain with the minor fixes necessary.

* All executable flags are stripped in the git repo; presumably the tarball passed through a Windoze machine. I had to chmod a+x jimtcl/configure jimtcl/autosetup/autosetup-find-tclsh and I just ran autoreconf -i to regenerate the main automake tooling which I had to do anyway due to automake versions. For some reason running autoreconf -i in the jimtcl directory results in a no-op configure script. Not sure why, but the included one worked on my system with +x.
* The WCH code generates errors, and -Werror is enabled by default in the build scripts, so you will need to run ./configure with --disable-werror
* Even though the configure script says Wlink support has been built by default, I found --enable-wlink was required for the driver to actually be compiled. Otherwise it tries to reference it at link time, but the files are not built and not linked, so undefined refs.

So great, I have a binary now, but there are no scripts that reference the wlink jtag driver or wchriscv target as far as I can tell, so it is not very useful at this point.

Luckily this is not binary content, so I should be able to extract it from MounRiver. Indeed, wch-riscv.cfg exists in the OpenOCD/bin directory of that distribution. Low and behold, it seems to be working:

Code: [Select]

Info : WCH-Link version 2.3
Info : wlink_init ok
Info : This adapter doesn't support configurable speed
Info : JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
Warn : Bypassing JTAG setup events due to errors
Info : [riscv.cpu.0] datacount=2 progbufsize=8
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40901125

I did not have time today to try building a hello world.

[SiliconWizard]

Just downloaded the datasheet to get a better idea of the whole thing.

[woofy]

Mine has arrived too.
I downloaded MounRiver IDE together with the example suite from GitHub and had no problem getting the blinky (GPIO_Toggle) example up and running.
Next I tried a CDC example (HID+CDC) which uses UART2. I couldn't be bothered to hook up the UART to anything so I hacked the example to increment what ever is sent and return it, much like Microchips USB CDC examples do.
That worked fine too.

As soon a time permits I will play with the TCP/IP examples.

Does anyone know if the API documentation for the TCP/IP stack is available anywhere?

[SpacedCowboy]

Just downloaded the datasheet to get a better idea of the whole thing.

Is that the Chinese or the English data sheet - if you have a link to an EN one, I'd appreciate it
 

[SiliconWizard]

Just downloaded the datasheet to get a better idea of the whole thing.

Is that the Chinese or the English data sheet - if you have a link to an EN one, I'd appreciate it

English. It's right on their website.
http://www.wch-ic.com/downloads/CH32V20x_30xDS0_PDF.html

[SpacedCowboy]

Maybe there's something wrong with my internet, but whenever I try to click on that link (and I found the same thing via GitHub) I get "site timed out" It looks as though the whole domain doesn't work for me...

[edit] Never mind - got it via the wayback machine.

[woofy]

You will also need the reference manual.
http://www.wch-ic.com/downloads/CH32FV2x_V3xRM_PDF.html

Unable to attach here as its over the 4MB size limit.

[SpacedCowboy]

You will also need the reference manual.
http://www.wch-ic.com/downloads/CH32FV2x_V3xRM_PDF.html

Unable to attach here as its over the 4MB size limit.

Yep, thanks - got both via wayback. Odd that I can't get there, but I tried it from my iPad, and 2 computers... Maybe they have a beef with AT&T (my ISP) or something...

[mon2]

Posting the latest reference manual from their website:

https://mega.nz/file/akEA0arC#VpeSAWl88QnP0Zzst9SqxT63kE4jk4x3Il1uYjbi34c

[newbrain]

Still waiting for mine.

I think the flight qualifies for the Guinness Book of Records as the longest in human history, as documented in the picture.

On a more serious note, I checked the code generated by MounRiver modified gcc when using __attribute__((interrupt("WCH-Interrupt-fast")));, supposedly using the hardware stacking if enabled at startup.

It would seem the only change is that return is using mret rather than ret, so it should be easy to provide a macro to emulate that with the regular gcc.

A maximum of three ISR that can happen to nest should be marked as fast, as far as I understand.

Vector Table Free is simpler, and can be combined with the above (I'll make some test of latency with the various combination when I get the board).

[newbrain]

All executable flags are stripped in the git repo; presumably the tarball passed through a Windoze machine.

My fault, sorry - knowing OpenOCD can be built for Windows too I did not think of expanding the tar on a Lunix machine.

[SiliconWizard]

On a more serious note, I checked the code generated by MounRiver modified gcc when using __attribute__((interrupt("WCH-Interrupt-fast")));, supposedly using the hardware stacking if enabled at startup.

It would seem the only change is that return is using mret rather than ret, so it should be easy to provide a macro to emulate that with the regular gcc.

I suspect there may be other things done using this attribute, depending on the content of the ISR. As I think this MCU supports nested interrupts, then I guess this is what this specific attribute would support. A bit like SiFive's: interrupt("SiFive-CLIC-preemptible").

Otherwise, the regular gcc supports the __attribute__((interrupt)) for RISC-V targets and it does emit mret, so if that's all you need, use this standard attribute instead. But keep in mind this basic RISC-V interrupt support can't be used for nested interrupts.

Of course, an alternative is otherwise to write your ISRs in assembly.

[ve7xen]

So what does this debugger customization originate from?

I gather there is a standard in-target debugger interface specification for RISC-V but other approaches / implementations have been used by various vendors.  So is this relating to WCH having some hardware debugger interface block (JTAG / cJTAG of some sort?) that is unique to their design and non-standard in the RISC-V ecosystem thus needing a new PC-side library to handle the JTAG to target operations in some way?  I guess the hardware pins and protocol could be standard JTAG but the MCU debug subsystem handling breakpoints, tracing, conditional operations, flash programming, etc. could be non-standard?

The OpenOCD modifications are basically just a driver for their 'Wlink' JTAG for debug and a similar driver for flashing. The chip has an SWD-style debug interface, which AFAICT isn't documented publicly, though it's presumably similar / identical to ARM SWD. It does look like the Wlink driver might depend on a binary DLL on Windows, if that matters to you. No idea what that contains, maybe some sort of shim to provide LibUSB functionality.

So basically is there no reason one could not use a standard RISC-V compiler / library tool chain to develop for this part, but flash programming and debugging would need custom code from the vendor to interface to openocd or whatever?

Are the runtime libraries and headers and so on all portable standard C / C++ which could work with GCC, etc.?

They have some custom CPU extensions that might require a non-standard compiler to make use of, but assuming it is a properly compliant RISC-V CPU, I don't think there's any reason you can't use the standard tools, you'll just miss out on the extensions. From what I have seen looking at the library code, it should work without modification, at least for the basics.

That said, I spent half an hour yesterday trying to get a very basic register-poking blinky running (using the standard tools, not MounRiver), and am getting hardfaults when the startup code (copied from MounRiver) jumps to user code. Does confirm the debug probe is working though . I haven't had time to dig any deeper yet but I assume I have done something wrong.

[woofy]

Has anyone got the openwch tcp server or client examples working?
 
I've tried both and the module seems lifeless. There is no network activity and even the initial debug message  "printf("TcpServer Test\r\n");" does nothing.
As I've mentioned earlier, I have the Blinky and CDC examples running OK.
The ETH_internal_10BASE-T_PHY example also works.

I'm running MounRiver IDE with the OpenWCH examples from Github on a Linux Mint 20.3 machine
I've also tried with Win10 (in a VM) with the same results.

[woofy]

I now have the tcp/ip server example running, It appears to be a bug in MounRiver IDE V1.10.
Version 1.70 has just been released and that works, but only for Windows. Linux is still on V1.10

[newbrain]

From what I have seen looking at the library code, it should work without modification, at least for the basics.

Note that the default startup code write some flags to enable hardware interrupt stacking.

I'm not sure how/if this affects normal - anon attribute marked - interrupt service routines, I should get my boards tomorrow so I'll be able to check shortly.

If one does not want to use the HW stack, it should be enough to write 0x0E (if nesting/preemption is still desired) instead of 0x1F in CSR 0x804 (see RM 9.5.3.1) - to be checked.

I just passed my Sveriges SändareAmatörer (ham radio operator, specifically the HAREC version) exam, so:
73 de SA0FZM!

[newbrain]

Got the boards, and made some experiment to see IRQ latency with the four combinations of VTF and HW stacking.

Pin 0 of Port C was toggled in a loop to drive EXTI0 on its negative edge, while pin 1 was only set in the same loop (not toggled), and reset as first thing in the IRS.
Only EXTI0 IRQ was enabled (so no nesting).

Code: [Select]

void EXTI0_IRQHandler(void)
{
    GPIOC->BCR = GPIO_Pin_1;
    EXTI_ClearITPendingBit(EXTI_Line0); /* Clear Flag */
}

The system clock was left at the default value of 72 MHz, my old t/c/rusty DS1054Z was used to measure the time difference between the falling edges.

Here are the results:

Code: [Select]

Latency ns             Latency cycles        Delta cycles

HWS | Off | On  |      HWS | Off | On  |
VTF |     |     |      VTF |     |     |
----+-----+-----+      ----+-----+-----+      ----+-----+-
Off | 446 | 210 |      Off |  32 |  15 |      HWS |  17 |
----+-----+-----+      ----+-----+-----+      ----+-----+-
On  | 418 | 182 |      On  |  30 |  13 |      VTF |   2 |
----+-----+-----+      ----+-----+-----+      ----+-----+-

VTF = Vector Table Free
HWS = Hardware Stacking

No pretence of extreme accuracy, just a data point, cycles approximated to the closest integer.
Hardware stacking makes, as expected, the largest difference. To enable or disable it, EXTI0_IRQHandler() was marked with:

Code: [Select]

#ifdef HWS
void EXTI0_IRQHandler(void) __attribute__((interrupt("WCH-Interrupt-fast")));
#else
void EXTI0_IRQHandler(void) __attribute__((interrupt("machine")));
#endif


I suspect there may be other things done using this attribute, depending on the content of the ISR.

You are quite certainly right, I'll check the generated assembly in the two cases (and study RISC-V exception and interrupt model).

Edit: used -Ofast instead of -Os, now results are more consistent.

[newbrain]

I suspect there may be other things done using this attribute, depending on the content of the ISR.

You are quite certainly right, I'll check the generated assembly in the two cases (and study RISC-V exception and interrupt model).

In fact, using __attribute__((interrupt("WCH-Interrupt-fast"))) is equivalent to __attribute__((naked)), plus asm volatile("mret") to return from the ISR.
The naked avoids that all the registers are stacked at entry (and popped at exit), and the mret will provide the return to user mode from machine mode.

At least, that worked with some simple test code...

[woofy]

Does anyone know if the API documentation for the TCP/IP stack is available anywhere?

I asked on github, it's coming!
https://github.com/openwch/ch32v307/issues/20

[martinribelotta]

Ok, with my ch32v307 board in hands, I have started coding a more confortable software environment than the MRS eclipse+modified gcc, and this is the (work in progress) result:

https://gitlab.com/eta-for-ci/ch32v307-gnumake

This provides the latest pheriperal library and the last rt-thread (4.0.4, not the oldest 3.x bundled with the example project)

By now, only gpio and usart driver is working (plus finsh shell) but in the sucessive days I will push more updates (specially adc/dac/pwm drivers plus usb dev driver)

The gcc required is risc-v embed (from xpack) but the oldest (8.x) gcc bundled with MRS toolchain work fine (my code do not use WCH-Interrupt-fast extension, but the CI is build around it for compatibillity)

The only MRS toolchain that this require now is the openocd with the MRS modifications (I was fail epically in compile it from the sources previously posted here)

[hydrabus]

For information I have released the toolchain to support RISC-V MCU with interrupt("WCH-Interrupt-fast")
See https://github.com/hydrausb3/riscv-none-elf-gcc-xpack
Pre-built version is also available here https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1
Any feedback are welcome as it has been tested only with HydraUSB3 v1 with WCH CH569 MCU so far

[martinribelotta]

That's amazing!

In a first view, the toolchain only have a subset of multilib activated...
Your team are planning to add more multilib options?

Or only the necesary to support the wch devices?