ch32v307, risc-v minicore with ethernet

[DiTBho]

Suggested here yesterday by a forum member, the ch32v307 looks very interesting (at least on the paper)

See here

risc-v@144Mhz
64K RAM
256K flash
Ethernet
USB2.0
i2c
spi
uart (8 channels!!!)
adc
rtc
...

very nice!

anyone going to use one? 

[hans]

Some STM32s also have 8 UARTs in 100QFP, I'm not that impressed by that single fact. However,  1Gbit ethernet Mac (on a MCU!) plus 480Mbit USB HS integrated phy, is quite interesting for a MCU. Both I haven't seen much before in a MCU, but perhaps that's also because they tend to be featured in way quicker chips. Those interfaces are quite overkill for a processor core at only 144MHz and 64K of RAM.
1Gbit ethernet can fill the complete RAM about 2000 times per second, and USB approx 940 times per second. It's absolutely crazy to think of any application that's so light on processing that it can work through 64K of data in 1ms (or 32K of data in 0.5ms etcetera). Perhaps fun to experiment with e.g. a A/D or D/A card that pumps data over ethernet. OTOH, it also depends a lot on the DMA controller and memory bus implementation: if that's done badly, it can make or break the utility quite a lot.

Integrated 10Mbit phy is quite nice to have. There was a recent discussion on the forum looking for such a device.

Some community sourced figures for Coremark (2.64/MHz) seems like this core is slower than a Cortex-m3/m4: https://gitee.com/elecb/ch32v307_core-mark
A Cortex-m3/m4 can reach 3.5 Coremark/MHz with a modern compiler.
It's actually more on par with a Cortex-m0.

[mon2]

Has anyone here heard of this company and used their ICs like this or other MCU ones?

Yes, WCH is a major player in Asia and had their start in the UART markets. We are in the same business and am impressed with the pricing for some of their silicon. Their target audience, in our opinion, appears to be the Asian sector based on the strength of technical support received to date. However, note that they offer a PCI 1S UART  @ $ 0.85 USD (pre-covid pricing) is almost impossible to believe. From reading through assorted UART docs, we do believe that numerous improvements could have been made but again, the price cannot be beat.

On the post of this thread - LCSC has a competition ongoing for which we asked about this 'free' kit promotion. Their reply for the kit being out of stock - NO ETA and not available. We only wanted to purchase the kit @ $10 USD to evaluate the core.

Next, we contacted WCH and they replied immediately and asked only to cover the shipping to us - we shared our DHL account - they shipped us 2 kits without charge. We have not yet had the chance to test the toolchain but hope to do so soon. Just too many other fires to put out due to the semiconductor shortages and screaming demand from OEMS to keep them running.

Summary: WCH is real but not sure on how much support there is currently for the English speaking markets.

LCSC has their silicon and kits in stock (as of this writing):

https://www.lcsc.com/product-detail/Development-Boards-Kits_WCH-Jiangsu-Qin-Heng-CH32V307V-EVT-R1_C2943980.html

Update - sharing a very responsible contact at the WCH factory:

Marketing Department：Jiamin Wang
Address: N0.18,Ningshuang Road,Qinheng Technology Park,Nanjing
Telephone number: 18951773252
Email: wjm[at]wch.cn
Nanjing Qinheng Microelectronics Co., Ltd.

[newbrain]

As I am a sucker for MCU dev boards, and had none with RISC-V, I've just ordered a couple from LCSC (they are in stock).
We'll see when they arrive.

As far as I could see, it should be possible to use GCC or clang, and the WCHlink on board can be bypassed to use some more supported probe (might it also be just a CMSIS-DAP with odd device and vendor Id?).

[westfw]

64K RAM
256K flash

Seems a bit tiny to run 8uarts worth of any modern networking stack.
Maybe it could run LAT.   

[ve7xen]

1Gbit ethernet can fill the complete RAM about 2000 times per second, and USB approx 940 times per second. It's absolutely crazy to think of any application that's so light on processing that it can work through 64K of data in 1ms (or 32K of data in 0.5ms etcetera). Perhaps fun to experiment with e.g. a A/D or D/A card that pumps data over ethernet. OTOH, it also depends a lot on the DMA controller and memory bus implementation: if that's done badly, it can make or break the utility quite a lot.

In both cases there is a wide gulf between 12Mbps FS USB and fully saturating the 480Mbps HS USB where a lot of applications live. GigE vs. 100M is probably tougher to justify, but there's probably not much difference in the complexity of the MAC so why not.

Integrated 10Mbit phy is quite nice to have. There was a recent discussion on the forum looking for such a device.

Definitely intriguing to get onto Ethernet with no external components. I don't think I've seen this choice to go with a 10M PHY onboard even though a much faster MAC is available, but I think it is interesting. Again, many applications that don't need much bandwidth but where having the Ethernet PHY integrated really simplifies and saves on the BOM.

The English datasheets and manuals look pretty complete and readable.

Thanks for the heads up, I will order a couple to play with.

[tszaboo]

Some STM32s also have 8 UARTs in 100QFP, I'm not that impressed by that single fact. However,  1Gbit ethernet Mac (on a MCU!) plus 480Mbit USB HS integrated phy, is quite interesting for a MCU. Both I haven't seen much before in a MCU, but perhaps that's also because they tend to be featured in way quicker chips. Those interfaces are quite overkill for a processor core at only 144MHz and 64K of RAM.
1Gbit ethernet can fill the complete RAM about 2000 times per second, and USB approx 940 times per second. It's absolutely crazy to think of any application that's so light on processing that it can work through 64K of data in 1ms (or 32K of data in 0.5ms etcetera). Perhaps fun to experiment with e.g. a A/D or D/A card that pumps data over ethernet. OTOH, it also depends a lot on the DMA controller and memory bus implementation: if that's done badly, it can make or break the utility quite a lot.

Integrated 10Mbit phy is quite nice to have. There was a recent discussion on the forum looking for such a device.

Some community sourced figures for Coremark seems like this core is slower than a Cortex-m3/m4: https://gitee.com/elecb/ch32v307_core-mark
A Cortex-m3/m4 can reach 3.5 Coremark/MHz with a modern compiler.
It's actually more on par with a Cortex-m0.

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?

[DiTBho]

64K RAM
256K flash

Seems a bit tiny to run 8uarts worth of any modern networking stack.
Maybe it could run LAT.   

Probably enough for udp/ip, not for tcp/ip. LAT is in the middle and sounds more than doable.

LAT specifies that if a computer communicating via LAT doesn't receive an acknowledgment within 80 ms for a packet it transmitted, it re-sends that packet.

This can clog a network, tcp/ip is better here, but more complex.

[woofy]

It looks like a very capable chip. Does this RISC-V4F have execute in place capabilities for external flash?

Not that I can see, it does not have QSPI. It does have SD card interface though.

Probably enough for udp/ip, not for tcp/ip.

There are example Tcp Client and Tcp Server examples on their github page.


It looks to be an intriguing chip, I've ordered a dev board to play with.

[martinribelotta]

I have a ch32v307 EVK and the chip is impressive...
The eth10M with on chip PHY is essentially a god-tier in my bussines (industrial control)
But I have only one complaint: the toolchain stack

 - GCC is risc-v embed from Liviu Ionescu (xPack dev tools maintainer) but modified to add WCH-Interrupt-fast attribute for interrupts (verified with grep on cc1, cc1plus and lto1 binaries)
 - OpenOCD is modified to add wlink protocol and ch32vXXX flash algorithm

Both programs are GPL and the source code is not available (at least in my knowledge)

This in a clean violation of GPL code in a very stupid point... the toolchain not have any value for the hardware vendor and remember me the stupid way of microchip licencing of gcc on PIC33/PIC24

Anyone know wath about the source code access? especially for gcc since the version packaged by MounRiver is a quite old (8.2.0)

PD: The only purponse of WCH-Interrupt-fast is prevent the tool make a frame stack on interrupt entry (because the core have a 4-level hardware stack for some interrupts). (see: http://www.wch.cn/downloads/QingKeV4_Processor_Manual_PDF.html)

This is easily handling with custom ASM code for interrupt entries and C function call but this is not the point... WCH was modify a full-GPL code and any binary holder of this toolchain have the rigth to ask the source code...
 

[newbrain]

I've ordered a dev board to play with.

I will order a couple to play with.

I've just ordered a couple from LCSC

And we all chose the right day to do that 

[DiTBho]

This in a clean violation of GPL code in a very stupid point... the toolchain not have any value for the hardware vendor and remember me the stupid way of microchip licencing of gcc on PIC33/PIC24

Yes, it is annoying. It also happens with Note2 and Note5 (eInk readers), but also with the new Fonera (routers), and who knows how many others ...

ah, OpenSource, we are all open with other people's sources ... 

[ve7xen]

I have a ch32v307 EVK and the chip is impressive...
The eth10M with on chip PHY is essentially a god-tier in my bussines (industrial control)
But I have only one complaint: the toolchain stack

 - GCC is risc-v embed from Liviu Ionescu (xPack dev tools maintainer) but modified to add WCH-Interrupt-fast attribute for interrupts (verified with grep on cc1, cc1plus and lto1 binaries)
 - OpenOCD is modified to add wlink protocol and ch32vXXX flash algorithm

Both programs are GPL and the source code is not available (at least in my knowledge)

This in a clean violation of GPL code in a very stupid point... the toolchain not have any value for the hardware vendor and remember me the stupid way of microchip licencing of gcc on PIC33/PIC24

Anyone know wath about the source code access? especially for gcc since the version packaged by MounRiver is a quite old (8.2.0)

PD: The only purponse of WCH-Interrupt-fast is prevent the tool make a frame stack on interrupt entry (because the core have a 4-level hardware stack for some interrupts). (see: http://www.wch.cn/downloads/QingKeV4_Processor_Manual_PDF.html)

This is easily handling with custom ASM code for interrupt entries and C function call but this is not the point... WCH was modify a full-GPL code and any binary holder of this toolchain have the rigth to ask the source code...

Totally agree about the licensing issues, they really need to straighten themselves out, and it would be a great benefit to adoption of their chips. Hopefully they come around soon.

As a practical matter, it seems that vanilla xPack RISCV GCC works fine and there are two separate forks of ch552tool with programming support via the bootloader here https://github.com/MarsTechHAN/ch552tool/pull/22 and here https://github.com/Pe3ucTop/ch552tool/tree/global_rework . Not too sure about 'WCH-Link'; on the ARM side it seems to be CMSIS-DAP compliant, but GigaDevices at least appears to use CMSIS-DAP for their RISC-V micros too, and this appears to work with OpenOCD, so I guess it (or another CMSIS-DAP programmer) works here too. We will soon find out...

[westfw]

  Quote

LAT specifies that if a computer communicating via LAT doesn't receive an acknowledgment within 80 ms for a packet it transmitted, it re-sends that packet.  This can clog a network

Hmm.  So says wikipedia, but that's not the way I remember it.  Their reference for that particular statement is a product announcement for an Ethernet Bridge that prioritized LAT, so it's "marketing" rather than technical analysis.  The actual Spec says there is an 80ms Circuit Timer, but that the retransmit time ought to be more like 1s.

• SERVER_CIRCUIT_TIMER - In the range 1-100. This paranleter specifies 10 nlillisecond intervals. (The value 8 is recomended - 80 milliseconds).
• SERVER_RETRANSMIT_TIMER - In the range 1 to 2 seconds.
• HOST_RETRANSMIT_TIMER - In the range 1 to 2 seconds.

Of course, that's not the point so much as that LAT was more-or-less designed to reduce the performance and hardware requirements of the servers.   (huh.  I have no idea what was inside a DEC LAT Server.  T11?)
A similar cisco TCP terminal server from the same era pretty much required at least 512k of memory (on a 68k), and it really wanted a lot of that to be RAM (so much dynamic memory allocation!)  But then, it typically had a bunch of other features as well...)
   

[newbrain]

A small update:
I asked MounRiver for the GPLed code, and just got an answer with the OpenOCD patches.
As for gcc, they say they are in development of a new version.

I'm now on a plane, I don't know what's inside the tar, but I'll share the code here or on GH later today.

[DiTBho]

So says wikipedia

Yup, but so also says the manual of my DEC-terminal. 80msec is the max value you can set 

[DiTBho]

A similar cisco TCP terminal server from the same era pretty much required at least 512k of memory (on a 68k), and it really wanted a lot of that to be RAM (so much dynamic memory allocation!)  But then, it typically had a bunch of other features as well...)

yup, 512Kbyte on 68k; 1Mbyte on Tektronix MIPS R3K for LAT + Vt100, 32Mbyte for x11+tcp/ip+twm+xterm+telnet

In my case, the challenge is less than 32Kbyte ram on 68HC11(1) for (simplified) Vt100(1) + LAT + CS8900 driver. I cannot allocate more ram, I will probably modify the LAT protocol to create something new and simpler.

64Kbyte is the double on ch32v307(1), but it's has the same challenge

(1) CPU/MPU coupled to a little CPLD + dual-port-RAM (2) for the VDU part. The part that manages VGA timing, video-text ram and PS/2 keyboard.
(2) 4Kbyte for { 80 colls, 43 rows, 1 color, no attributes, hw-Vscroll }

[martinribelotta]

Nice colaboration! Many times, the only reason for non published source code is the ignorance of the GPL derived sources or simply a very tight schedule!

You can publish these patchs in github or via gits? I can integrate in openocd devel and send the patches for review (at least)

This repo contains a reverse eengineering of wlink protocol:
https://github.com/fxsheep/openocd_wchlink-rv
But lacks flash write support

[newbrain]

Nice colaboration! Many times, the only reason for non published source code is the ignorance of the GPL derived sources or simply a very tight schedule!

Yes, let's not assume malice, still no GCC, but they answered in a very short time!

Just got home and untarred the file.

As far as I can see (I have no familiarity whatsoever with OpenOCD codebase) this is the full source of their version.
The driver for WCHlink is in ./src/jtag/drivers/wlink.c (at least) and correctly marked as GPL - this shows at least a modicum of good intentions.
EtA: I found other references to CH32Vxxx in ./src/flash/nor/wchriscv.c

Everyone interested can find the whole shebang here:
https://github.com/newbrain/riscv-openocd-wch.git

I did not try a compare against OpenOCD code.

[newbrain]

BTW: a little note about GPL.
GPL does not mandate that the source be accessible to everyone, but only to the users of the SW.

That said:

• Nowadays, the simplest way to fulfil the rules is to make the source available for public download, especially since...
• ...the user can in turn redistribute it freely!

Some time ago I investigated about how many of our customers really requested for for our code (some of it is pushed upstream when suitable for general consumption, some is on public repos, but for the specific LGPL2 product I was involved in it is distributed on request).

I was told "We got about three requests in ten years".

[SiliconWizard]

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.

[ve7xen]

@newbrain Thanks a lot for reaching out to WCH and posting their code publicly!

One of the main 'uses' of the GPL's 'viral' clause is for improvements / additions to be backported to upstream, regardless of whether the downstream developer is interested in doing that themselves. So the main 'user' of that code is going to be developers of the upstream project, and once it gets consumed this way, it's not really needed any longer. It's not that surprising that the number of requests is low, but that doesn't necessarily mean there isn't value in getting that code back to upstream.

The 'better' model of course would be for the vendor to just participate in the upstream development process, in which case the GPL's viral clause isn't really relevant, since their patches are being directly included.

Mostly end users are not going to be too interested in building/running a vendor fork, but there might be many users of the functionality once it gets backported upstream. Like in this situation, probably not many people will consume the WCH openocd fork directly, and may even choose to avoid those chips until it's integrated, but the protocol will get integrated upstream and lots of people will use that.

[tszaboo]

It looks like a very capable chip. Does this RISC-V4F have execute in place capabilities for external flash?

Not that I can see, it does not have QSPI. It does have SD card interface though.

Probably enough for udp/ip, not for tcp/ip.

There are example Tcp Client and Tcp Server examples on their github page.


It looks to be an intriguing chip, I've ordered a dev board to play with.

That's true, though I'm not sure if XiP requires QSPI, maybe it does. In any case I checked the datasheet, and the instruction decode is directly wired to the flash and SRAM so no.
Too bad, I honestly think the amount of RAM and Flash could be a bottleneck for this. If you start using more than 3-4 of those hardware communication channels, the usual bloatware will very quickly eat up that memory.
Ah well, it wouldve been nice to run micropython on this.

[SiliconWizard]

The 'better' model of course would be for the vendor to just participate in the upstream development process, in which case the GPL's viral clause isn't really relevant, since their patches are being directly included.

I agree, but even if the vendor has the best intentions here, it just doesn't always work.

You can ask people that tried submitting code to mainline GCC for instance, and see how far they have gone. It's a very tedious, and often frustrating process. And, if the feature you submit only concerns a particular optimization for a particular chip of a particular vendor, you get basically priority zero and your submission will get to the bottom of the pile, and it might take several years before it's included, if ever. And I don't even blame. That makes sense. You've got to set priorities when managing projects of this size.

So, while certainly not the ideal situation, I can understand companies maintaining their own fork, if they want to get anywhere.

[westfw]

so also says the manual of my DEC-terminal. 80msec is the max value you can set

Reference?  I scanned a few DecServer online manuals, and it looks like you can usually only set the retransmission COUNT.  Also, it doesn't make a lot of sense for the "circuit timer" and the "retransmission timer" to be the same.

[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?

[hydrabus]

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?

What do you mean by "add more multilib options?" ?

Like explained in https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1 (it is a fork from original https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/tag/v12.2.0-1)
All multilib are enabled using bash ${HOME}/Work/riscv-none-elf-gcc-xpack.git/scripts/helper/build.sh --develop --disable-tests --linux64 --win64
So it support all RISC-V with addition of special interrupt("WCH-Interrupt-fast") for WCH RISC-V and nothing has been removed

[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?

What do you mean by "add more multilib options?" ?

Like explained in https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1 (it is a fork from original https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/tag/v12.2.0-1)
All multilib are enabled using bash ${HOME}/Work/riscv-none-elf-gcc-xpack.git/scripts/helper/build.sh --develop --disable-tests --linux64 --win64
So it support all RISC-V with addition of special interrupt("WCH-Interrupt-fast") for WCH RISC-V and nothing has been removed

The original xpack-riscv-none-elf 12.2.0-1 have this content in {install prefix}/xpack-riscv-none-elf-gcc-12.2.0-1/riscv-none-elf/lib/:

Code: [Select]

crt0.o         libgfortran.spec  libnosys.a          libsupc++.a       rv32eac   rv32i            rv32iaf_zicsr   rv32im            rv32imc          rv64ia           rv64ic          rv64ima           rv64imc          sim.specs
ldscripts      libgloss.a        libsemihost.a       libsupc++_nano.a  rv32ec    rv32ia           rv32ic          rv32ima           rv32imfc_zicsr   rv64iac          rv64ifc_zicsr   rv64imac          rv64imfc_zicsr
libc.a         libgloss_nano.a   libsim.a            nano.specs        rv32em    rv32iac          rv32ifc_zicsr   rv32imafc_zicsr   rv32imfdc_zicsr  rv64iafc_zicsr   rv64ifdc_zicsr  rv64imafc_zicsr   rv64imfdc_zicsr
libc_nano.a    libg_nano.a       libstdc++.a         nosys.specs       rv32ema   rv32iafc_zicsr   rv32ifdc_zicsr  rv32imafdc_zicsr  rv32imfd_zicsr   rv64iafdc_zicsr  rv64ifd_zicsr   rv64imafdc_zicsr  rv64imfd_zicsr
libg.a         libm.a            libstdc++.a-gdb.py  rv32e             rv32emac  rv32iafdc_zicsr  rv32ifd_zicsr   rv32imafd_zicsr   rv32imf_zicsr    rv64iafd_zicsr   rv64if_zicsr    rv64imafd_zicsr   rv64imf_zicsr
libgfortran.a  libm_nano.a       libstdc++_nano.a    rv32ea            rv32emc   rv32iafd_zicsr   rv32if_zicsr    rv32imaf_zicsr    rv64i            rv64iaf_zicsr    rv64im          rv64imaf_zicsr    semihost.specs

And your compilation have only this:

Code: [Select]

crt0.o     libc.a       libg.a         libgfortran.spec  libgloss_nano.a  libm.a       libnosys.a     libsim.a     libstdc++.a-gdb.py  libsupc++.a       nano.specs   rv32emac  rv64imac        sim.specs
ldscripts  libc_nano.a  libgfortran.a  libgloss.a        libg_nano.a      libm_nano.a  libsemihost.a  libstdc++.a  libstdc++_nano.a    libsupc++_nano.a  nosys.specs  rv32ima   semihost.specs

You can verify the bundled multilib libraries with -print-multi-lib gcc option:

Code: [Select]

$> /opt/xpack-riscv-none-elf-gcc-12.2.0-1-wch/bin/riscv-none-elf-gcc -print-multi-lib
.;
rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e
rv32ima/ilp32;@march=rv32ima@mabi=ilp32
rv64imac/lp64;@march=rv64imac@mabi=lp64

$> /opt/xpack-riscv-none-elf-gcc-12.2.0-1/bin/riscv-none-elf-gcc -print-multi-lib
.;
rv32e/ilp32e;@march=rv32e@mabi=ilp32e
rv32ea/ilp32e;@march=rv32ea@mabi=ilp32e
rv32eac/ilp32e;@march=rv32eac@mabi=ilp32e
rv32ec/ilp32e;@march=rv32ec@mabi=ilp32e
rv32em/ilp32e;@march=rv32em@mabi=ilp32e
rv32ema/ilp32e;@march=rv32ema@mabi=ilp32e
rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e
rv32emc/ilp32e;@march=rv32emc@mabi=ilp32e
rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32ia/ilp32;@march=rv32ia@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32iaf_zicsr/ilp32f;@march=rv32iaf_zicsr@mabi=ilp32f
rv32iafc_zicsr/ilp32f;@march=rv32iafc_zicsr@mabi=ilp32f
rv32iafd_zicsr/ilp32d;@march=rv32iafd_zicsr@mabi=ilp32d
rv32iafdc_zicsr/ilp32d;@march=rv32iafdc_zicsr@mabi=ilp32d
rv32ic/ilp32;@march=rv32ic@mabi=ilp32
rv32if_zicsr/ilp32f;@march=rv32if_zicsr@mabi=ilp32f
rv32ifc_zicsr/ilp32f;@march=rv32ifc_zicsr@mabi=ilp32f
rv32ifd_zicsr/ilp32d;@march=rv32ifd_zicsr@mabi=ilp32d
rv32ifdc_zicsr/ilp32d;@march=rv32ifdc_zicsr@mabi=ilp32d
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32ima/ilp32;@march=rv32ima@mabi=ilp32
rv32imaf_zicsr/ilp32f;@march=rv32imaf_zicsr@mabi=ilp32f
rv32imafc_zicsr/ilp32f;@march=rv32imafc_zicsr@mabi=ilp32f
rv32imafd_zicsr/ilp32d;@march=rv32imafd_zicsr@mabi=ilp32d
rv32imafdc_zicsr/ilp32d;@march=rv32imafdc_zicsr@mabi=ilp32d
rv32imc/ilp32;@march=rv32imc@mabi=ilp32
rv32imf_zicsr/ilp32f;@march=rv32imf_zicsr@mabi=ilp32f
rv32imfc_zicsr/ilp32f;@march=rv32imfc_zicsr@mabi=ilp32f
rv32imfd_zicsr/ilp32d;@march=rv32imfd_zicsr@mabi=ilp32d
rv32imfdc_zicsr/ilp32d;@march=rv32imfdc_zicsr@mabi=ilp32d
rv64i/lp64;@march=rv64i@mabi=lp64
rv64ia/lp64;@march=rv64ia@mabi=lp64
rv64iac/lp64;@march=rv64iac@mabi=lp64
rv64iaf_zicsr/lp64f;@march=rv64iaf_zicsr@mabi=lp64f
rv64iafc_zicsr/lp64f;@march=rv64iafc_zicsr@mabi=lp64f
rv64iafd_zicsr/lp64d;@march=rv64iafd_zicsr@mabi=lp64d
rv64iafdc_zicsr/lp64d;@march=rv64iafdc_zicsr@mabi=lp64d
rv64ic/lp64;@march=rv64ic@mabi=lp64
rv64if_zicsr/lp64f;@march=rv64if_zicsr@mabi=lp64f
rv64ifc_zicsr/lp64f;@march=rv64ifc_zicsr@mabi=lp64f
rv64ifd_zicsr/lp64d;@march=rv64ifd_zicsr@mabi=lp64d
rv64ifdc_zicsr/lp64d;@march=rv64ifdc_zicsr@mabi=lp64d
rv64im/lp64;@march=rv64im@mabi=lp64
rv64ima/lp64;@march=rv64ima@mabi=lp64
rv64imac/lp64;@march=rv64imac@mabi=lp64
rv64imaf_zicsr/lp64f;@march=rv64imaf_zicsr@mabi=lp64f
rv64imafc_zicsr/lp64f;@march=rv64imafc_zicsr@mabi=lp64f
rv64imafd_zicsr/lp64d;@march=rv64imafd_zicsr@mabi=lp64d
rv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64d
rv64imc/lp64;@march=rv64imc@mabi=lp64
rv64imf_zicsr/lp64f;@march=rv64imf_zicsr@mabi=lp64f
rv64imfc_zicsr/lp64f;@march=rv64imfc_zicsr@mabi=lp64f
rv64imfd_zicsr/lp64d;@march=rv64imfd_zicsr@mabi=lp64d
rv64imfdc_zicsr/lp64d;@march=rv64imfdc_zicsr@mabi=lp64d

The ch32v30x have a QingKe v4f (imafc) core and ch569 have v3a (maybe a typo for v4a?) that claim be a rv32imac.

In any case, your toolchain lacks the c and f extentions for rv32 (have rv32emac, rv32ima and rv64imac but not rv32imac or rv32imacf) that be crucial in many cases (c is a big improve of code size reduction and f is essential if you work with floating point primitives)

I'm investigating what is the problem with the scripts that generate this behaviour in your compilation...

[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?

What do you mean by "add more multilib options?" ?

Like explained in [url]https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1[/url] (it is a fork from original [url]https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/tag/v12.2.0-1[/url])
All multilib are enabled using bash ${HOME}/Work/riscv-none-elf-gcc-xpack.git/scripts/helper/build.sh --develop --disable-tests --linux64 --win64
So it support all RISC-V with addition of special interrupt("WCH-Interrupt-fast") for WCH RISC-V and nothing has been removed

The original xpack-riscv-none-elf 12.2.0-1 have this content in {install prefix}/xpack-riscv-none-elf-gcc-12.2.0-1/riscv-none-elf/lib/:

Code: [Select]

crt0.o         libgfortran.spec  libnosys.a          libsupc++.a       rv32eac   rv32i            rv32iaf_zicsr   rv32im            rv32imc          rv64ia           rv64ic          rv64ima           rv64imc          sim.specs
ldscripts      libgloss.a        libsemihost.a       libsupc++_nano.a  rv32ec    rv32ia           rv32ic          rv32ima           rv32imfc_zicsr   rv64iac          rv64ifc_zicsr   rv64imac          rv64imfc_zicsr
libc.a         libgloss_nano.a   libsim.a            nano.specs        rv32em    rv32iac          rv32ifc_zicsr   rv32imafc_zicsr   rv32imfdc_zicsr  rv64iafc_zicsr   rv64ifdc_zicsr  rv64imafc_zicsr   rv64imfdc_zicsr
libc_nano.a    libg_nano.a       libstdc++.a         nosys.specs       rv32ema   rv32iafc_zicsr   rv32ifdc_zicsr  rv32imafdc_zicsr  rv32imfd_zicsr   rv64iafdc_zicsr  rv64ifd_zicsr   rv64imafdc_zicsr  rv64imfd_zicsr
libg.a         libm.a            libstdc++.a-gdb.py  rv32e             rv32emac  rv32iafdc_zicsr  rv32ifd_zicsr   rv32imafd_zicsr   rv32imf_zicsr    rv64iafd_zicsr   rv64if_zicsr    rv64imafd_zicsr   rv64imf_zicsr
libgfortran.a  libm_nano.a       libstdc++_nano.a    rv32ea            rv32emc   rv32iafd_zicsr   rv32if_zicsr    rv32imaf_zicsr    rv64i            rv64iaf_zicsr    rv64im          rv64imaf_zicsr    semihost.specs

And your compilation have only this:

Code: [Select]

crt0.o     libc.a       libg.a         libgfortran.spec  libgloss_nano.a  libm.a       libnosys.a     libsim.a     libstdc++.a-gdb.py  libsupc++.a       nano.specs   rv32emac  rv64imac        sim.specs
ldscripts  libc_nano.a  libgfortran.a  libgloss.a        libg_nano.a      libm_nano.a  libsemihost.a  libstdc++.a  libstdc++_nano.a    libsupc++_nano.a  nosys.specs  rv32ima   semihost.specs

You can verify the bundled multilib libraries with -print-multi-lib gcc option:

Code: [Select]

$> /opt/xpack-riscv-none-elf-gcc-12.2.0-1-wch/bin/riscv-none-elf-gcc -print-multi-lib
.;
rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e
rv32ima/ilp32;@march=rv32ima@mabi=ilp32
rv64imac/lp64;@march=rv64imac@mabi=lp64

$> /opt/xpack-riscv-none-elf-gcc-12.2.0-1/bin/riscv-none-elf-gcc -print-multi-lib
.;
rv32e/ilp32e;@march=rv32e@mabi=ilp32e
rv32ea/ilp32e;@march=rv32ea@mabi=ilp32e
rv32eac/ilp32e;@march=rv32eac@mabi=ilp32e
rv32ec/ilp32e;@march=rv32ec@mabi=ilp32e
rv32em/ilp32e;@march=rv32em@mabi=ilp32e
rv32ema/ilp32e;@march=rv32ema@mabi=ilp32e
rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e
rv32emc/ilp32e;@march=rv32emc@mabi=ilp32e
rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32ia/ilp32;@march=rv32ia@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32iaf_zicsr/ilp32f;@march=rv32iaf_zicsr@mabi=ilp32f
rv32iafc_zicsr/ilp32f;@march=rv32iafc_zicsr@mabi=ilp32f
rv32iafd_zicsr/ilp32d;@march=rv32iafd_zicsr@mabi=ilp32d
rv32iafdc_zicsr/ilp32d;@march=rv32iafdc_zicsr@mabi=ilp32d
rv32ic/ilp32;@march=rv32ic@mabi=ilp32
rv32if_zicsr/ilp32f;@march=rv32if_zicsr@mabi=ilp32f
rv32ifc_zicsr/ilp32f;@march=rv32ifc_zicsr@mabi=ilp32f
rv32ifd_zicsr/ilp32d;@march=rv32ifd_zicsr@mabi=ilp32d
rv32ifdc_zicsr/ilp32d;@march=rv32ifdc_zicsr@mabi=ilp32d
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32ima/ilp32;@march=rv32ima@mabi=ilp32
rv32imaf_zicsr/ilp32f;@march=rv32imaf_zicsr@mabi=ilp32f
rv32imafc_zicsr/ilp32f;@march=rv32imafc_zicsr@mabi=ilp32f
rv32imafd_zicsr/ilp32d;@march=rv32imafd_zicsr@mabi=ilp32d
rv32imafdc_zicsr/ilp32d;@march=rv32imafdc_zicsr@mabi=ilp32d
rv32imc/ilp32;@march=rv32imc@mabi=ilp32
rv32imf_zicsr/ilp32f;@march=rv32imf_zicsr@mabi=ilp32f
rv32imfc_zicsr/ilp32f;@march=rv32imfc_zicsr@mabi=ilp32f
rv32imfd_zicsr/ilp32d;@march=rv32imfd_zicsr@mabi=ilp32d
rv32imfdc_zicsr/ilp32d;@march=rv32imfdc_zicsr@mabi=ilp32d
rv64i/lp64;@march=rv64i@mabi=lp64
rv64ia/lp64;@march=rv64ia@mabi=lp64
rv64iac/lp64;@march=rv64iac@mabi=lp64
rv64iaf_zicsr/lp64f;@march=rv64iaf_zicsr@mabi=lp64f
rv64iafc_zicsr/lp64f;@march=rv64iafc_zicsr@mabi=lp64f
rv64iafd_zicsr/lp64d;@march=rv64iafd_zicsr@mabi=lp64d
rv64iafdc_zicsr/lp64d;@march=rv64iafdc_zicsr@mabi=lp64d
rv64ic/lp64;@march=rv64ic@mabi=lp64
rv64if_zicsr/lp64f;@march=rv64if_zicsr@mabi=lp64f
rv64ifc_zicsr/lp64f;@march=rv64ifc_zicsr@mabi=lp64f
rv64ifd_zicsr/lp64d;@march=rv64ifd_zicsr@mabi=lp64d
rv64ifdc_zicsr/lp64d;@march=rv64ifdc_zicsr@mabi=lp64d
rv64im/lp64;@march=rv64im@mabi=lp64
rv64ima/lp64;@march=rv64ima@mabi=lp64
rv64imac/lp64;@march=rv64imac@mabi=lp64
rv64imaf_zicsr/lp64f;@march=rv64imaf_zicsr@mabi=lp64f
rv64imafc_zicsr/lp64f;@march=rv64imafc_zicsr@mabi=lp64f
rv64imafd_zicsr/lp64d;@march=rv64imafd_zicsr@mabi=lp64d
rv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64d
rv64imc/lp64;@march=rv64imc@mabi=lp64
rv64imf_zicsr/lp64f;@march=rv64imf_zicsr@mabi=lp64f
rv64imfc_zicsr/lp64f;@march=rv64imfc_zicsr@mabi=lp64f
rv64imfd_zicsr/lp64d;@march=rv64imfd_zicsr@mabi=lp64d
rv64imfdc_zicsr/lp64d;@march=rv64imfdc_zicsr@mabi=lp64d

The ch32v30x have a QingKe v4f (imafc) core and ch569 have v3a (maybe a typo for v4a?) that claim be a rv32imac.

In any case, your toolchain lacks the c and f extentions for rv32 (have rv32emac, rv32ima and rv64imac but not rv32imac or rv32imacf) that be crucial in many cases (c is a big improve of code size reduction and f is essential if you work with floating point primitives)

I'm investigating what is the problem with the scripts that generate this behaviour in your compilation...

I found the cause of the miltilib lack...
https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/discussions/6

When you use the flag --develop this restrict the multilib options due to improve the compilation time.

You can remove --develop flag on your build and reupload the toolchain? This is very usefull for many peoples like me that maintain a separated startup/interrupt code due to the lack of "wch-interrupt-fast" implementation in a vanilla xpack-riscv-gcc

[PavelS]

Hello! I need to use alternative pins for uart5 (problems with cross connection). TX-B.4 RX-B.5 vs TX-C.12 RX-D.2 the original.
Using MounRiver studio with standard libraries.
Code:

Code: [Select]

(config USART)

    GPIO_PinRemapConfig(GPIO_PartialRemap_USART5, ENABLE);
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_UART5, ENABLE);
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC | RCC_APB2Periph_GPIOD | RCC_APB2Periph_GPIOB | RCC_APB2Periph_AFIO, ENABLE);

    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
    GPIO_Init(GPIOB, &GPIO_InitStructure);
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
    GPIO_Init(GPIOB, &GPIO_InitStructure);

    USART_InitStructure.USART_BaudRate = 115200;
    USART_InitStructure.USART_WordLength = USART_WordLength_8b;
    USART_InitStructure.USART_StopBits = USART_StopBits_1;
    USART_InitStructure.USART_Parity = USART_Parity_No;
    USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
    USART_InitStructure.USART_Mode = USART_Mode_Tx | USART_Mode_Rx;

    USART_Init(UART5, &USART_InitStructure);
    USART_ITConfig(UART5, USART_IT_RXNE, ENABLE);

    NVIC_InitStructure.NVIC_IRQChannel = UART5_IRQn;
    NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
    NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
    NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
    NVIC_Init(&NVIC_InitStructure);

    USART_Cmd(UART5, ENABLE);


But this code didn't work.

In the original PIN configuration, everything worked correctly.
Please help me

[hydrabus]

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?

What do you mean by "add more multilib options?" ?

Like explained in [url]https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1[/url] (it is a fork from original [url]https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/tag/v12.2.0-1[/url])
All multilib are enabled using bash ${HOME}/Work/riscv-none-elf-gcc-xpack.git/scripts/helper/build.sh --develop --disable-tests --linux64 --win64
So it support all RISC-V with addition of special interrupt("WCH-Interrupt-fast") for WCH RISC-V and nothing has been removed

The original xpack-riscv-none-elf 12.2.0-1 have this content in {install prefix}/xpack-riscv-none-elf-gcc-12.2.0-1/riscv-none-elf/lib/:

Code: [Select]

crt0.o         libgfortran.spec  libnosys.a          libsupc++.a       rv32eac   rv32i            rv32iaf_zicsr   rv32im            rv32imc          rv64ia           rv64ic          rv64ima           rv64imc          sim.specs
ldscripts      libgloss.a        libsemihost.a       libsupc++_nano.a  rv32ec    rv32ia           rv32ic          rv32ima           rv32imfc_zicsr   rv64iac          rv64ifc_zicsr   rv64imac          rv64imfc_zicsr
libc.a         libgloss_nano.a   libsim.a            nano.specs        rv32em    rv32iac          rv32ifc_zicsr   rv32imafc_zicsr   rv32imfdc_zicsr  rv64iafc_zicsr   rv64ifdc_zicsr  rv64imafc_zicsr   rv64imfdc_zicsr
libc_nano.a    libg_nano.a       libstdc++.a         nosys.specs       rv32ema   rv32iafc_zicsr   rv32ifdc_zicsr  rv32imafdc_zicsr  rv32imfd_zicsr   rv64iafdc_zicsr  rv64ifd_zicsr   rv64imafdc_zicsr  rv64imfd_zicsr
libg.a         libm.a            libstdc++.a-gdb.py  rv32e             rv32emac  rv32iafdc_zicsr  rv32ifd_zicsr   rv32imafd_zicsr   rv32imf_zicsr    rv64iafd_zicsr   rv64if_zicsr    rv64imafd_zicsr   rv64imf_zicsr
libgfortran.a  libm_nano.a       libstdc++_nano.a    rv32ea            rv32emc   rv32iafd_zicsr   rv32if_zicsr    rv32imaf_zicsr    rv64i            rv64iaf_zicsr    rv64im          rv64imaf_zicsr    semihost.specs

And your compilation have only this:

Code: [Select]

crt0.o     libc.a       libg.a         libgfortran.spec  libgloss_nano.a  libm.a       libnosys.a     libsim.a     libstdc++.a-gdb.py  libsupc++.a       nano.specs   rv32emac  rv64imac        sim.specs
ldscripts  libc_nano.a  libgfortran.a  libgloss.a        libg_nano.a      libm_nano.a  libsemihost.a  libstdc++.a  libstdc++_nano.a    libsupc++_nano.a  nosys.specs  rv32ima   semihost.specs

You can verify the bundled multilib libraries with -print-multi-lib gcc option:

Code: [Select]

$> /opt/xpack-riscv-none-elf-gcc-12.2.0-1-wch/bin/riscv-none-elf-gcc -print-multi-lib
.;
rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e
rv32ima/ilp32;@march=rv32ima@mabi=ilp32
rv64imac/lp64;@march=rv64imac@mabi=lp64

$> /opt/xpack-riscv-none-elf-gcc-12.2.0-1/bin/riscv-none-elf-gcc -print-multi-lib
.;
rv32e/ilp32e;@march=rv32e@mabi=ilp32e
rv32ea/ilp32e;@march=rv32ea@mabi=ilp32e
rv32eac/ilp32e;@march=rv32eac@mabi=ilp32e
rv32ec/ilp32e;@march=rv32ec@mabi=ilp32e
rv32em/ilp32e;@march=rv32em@mabi=ilp32e
rv32ema/ilp32e;@march=rv32ema@mabi=ilp32e
rv32emac/ilp32e;@march=rv32emac@mabi=ilp32e
rv32emc/ilp32e;@march=rv32emc@mabi=ilp32e
rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32ia/ilp32;@march=rv32ia@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32iaf_zicsr/ilp32f;@march=rv32iaf_zicsr@mabi=ilp32f
rv32iafc_zicsr/ilp32f;@march=rv32iafc_zicsr@mabi=ilp32f
rv32iafd_zicsr/ilp32d;@march=rv32iafd_zicsr@mabi=ilp32d
rv32iafdc_zicsr/ilp32d;@march=rv32iafdc_zicsr@mabi=ilp32d
rv32ic/ilp32;@march=rv32ic@mabi=ilp32
rv32if_zicsr/ilp32f;@march=rv32if_zicsr@mabi=ilp32f
rv32ifc_zicsr/ilp32f;@march=rv32ifc_zicsr@mabi=ilp32f
rv32ifd_zicsr/ilp32d;@march=rv32ifd_zicsr@mabi=ilp32d
rv32ifdc_zicsr/ilp32d;@march=rv32ifdc_zicsr@mabi=ilp32d
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32ima/ilp32;@march=rv32ima@mabi=ilp32
rv32imaf_zicsr/ilp32f;@march=rv32imaf_zicsr@mabi=ilp32f
rv32imafc_zicsr/ilp32f;@march=rv32imafc_zicsr@mabi=ilp32f
rv32imafd_zicsr/ilp32d;@march=rv32imafd_zicsr@mabi=ilp32d
rv32imafdc_zicsr/ilp32d;@march=rv32imafdc_zicsr@mabi=ilp32d
rv32imc/ilp32;@march=rv32imc@mabi=ilp32
rv32imf_zicsr/ilp32f;@march=rv32imf_zicsr@mabi=ilp32f
rv32imfc_zicsr/ilp32f;@march=rv32imfc_zicsr@mabi=ilp32f
rv32imfd_zicsr/ilp32d;@march=rv32imfd_zicsr@mabi=ilp32d
rv32imfdc_zicsr/ilp32d;@march=rv32imfdc_zicsr@mabi=ilp32d
rv64i/lp64;@march=rv64i@mabi=lp64
rv64ia/lp64;@march=rv64ia@mabi=lp64
rv64iac/lp64;@march=rv64iac@mabi=lp64
rv64iaf_zicsr/lp64f;@march=rv64iaf_zicsr@mabi=lp64f
rv64iafc_zicsr/lp64f;@march=rv64iafc_zicsr@mabi=lp64f
rv64iafd_zicsr/lp64d;@march=rv64iafd_zicsr@mabi=lp64d
rv64iafdc_zicsr/lp64d;@march=rv64iafdc_zicsr@mabi=lp64d
rv64ic/lp64;@march=rv64ic@mabi=lp64
rv64if_zicsr/lp64f;@march=rv64if_zicsr@mabi=lp64f
rv64ifc_zicsr/lp64f;@march=rv64ifc_zicsr@mabi=lp64f
rv64ifd_zicsr/lp64d;@march=rv64ifd_zicsr@mabi=lp64d
rv64ifdc_zicsr/lp64d;@march=rv64ifdc_zicsr@mabi=lp64d
rv64im/lp64;@march=rv64im@mabi=lp64
rv64ima/lp64;@march=rv64ima@mabi=lp64
rv64imac/lp64;@march=rv64imac@mabi=lp64
rv64imaf_zicsr/lp64f;@march=rv64imaf_zicsr@mabi=lp64f
rv64imafc_zicsr/lp64f;@march=rv64imafc_zicsr@mabi=lp64f
rv64imafd_zicsr/lp64d;@march=rv64imafd_zicsr@mabi=lp64d
rv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64d
rv64imc/lp64;@march=rv64imc@mabi=lp64
rv64imf_zicsr/lp64f;@march=rv64imf_zicsr@mabi=lp64f
rv64imfc_zicsr/lp64f;@march=rv64imfc_zicsr@mabi=lp64f
rv64imfd_zicsr/lp64d;@march=rv64imfd_zicsr@mabi=lp64d
rv64imfdc_zicsr/lp64d;@march=rv64imfdc_zicsr@mabi=lp64d

The ch32v30x have a QingKe v4f (imafc) core and ch569 have v3a (maybe a typo for v4a?) that claim be a rv32imac.

In any case, your toolchain lacks the c and f extentions for rv32 (have rv32emac, rv32ima and rv64imac but not rv32imac or rv32imacf) that be crucial in many cases (c is a big improve of code size reduction and f is essential if you work with floating point primitives)

I'm investigating what is the problem with the scripts that generate this behaviour in your compilation...

I found the cause of the miltilib lack...
[url]https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/discussions/6[/url]

When you use the flag --develop this restrict the multilib options due to improve the compilation time.

You can remove --develop flag on your build and reupload the toolchain? This is very usefull for many peoples like me that maintain a separated startup/interrupt code due to the lack of "wch-interrupt-fast" implementation in a vanilla xpack-riscv-gcc

Update:
Thanks for the details I have rebuild it see https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1

[mean00]

I'm posting this in case it can help someone.
 
I've modified the nice LLVM-embedded-toolchain-for-Arm project so that it builds a standalone clang/llvm+picolibc toolchain for riscv32
(tested on linux only, might work or not on windows).

I'm using it with the CH32V307, without too much issue so far (see below). Better to use clang if you do a mix of c++ & rust.

The modification is very small, the original project is very well done

https://github.com/mean00/LLVM-embedded-toolchain-for-rv32.git

It is experimental, but works nicely so far for me, including lto.

Some notes  :
It should be mostly a drop-in replacement for gcc with the following :
- you need to add --target=riscv32  to your cflags i.e.
 -march=rv32imac -mabi=ilp32  => --target=riscv32 -march=rv32imac -mabi=ilp32
- Clang linker script  is mostly compatible with gcc/ld one, but you may have to tweak it a bit.
- There is tiny compatibility between gcc & clang, like removing .func and .endfunc in asm files. Nothing painful.
- The above toolchain does not contain  the fast interrupt stuff, i  think you can get by with asm("mret")+ naked or something similar so that it works everywhere without every toolchain (not looked into it deeply yet).
- You still have to use gnu-gdb to debug
- The generated code size is similar to the one with gcc 12 + picolibc

Your typical build script is :
mkdir build && cd build && cmake -G Ninja && ninja && ninja  package-llvm-toolchain

/!\ You may have to create a symlink : ln -s $PWD/build/_deps/llvmproject-src/llvm/lib lib


Notice : It takes a while to build

[paf]

About the CH32V307:

There is a nice Chinese development board called Chitu/OpenCH: 
https://gitee.com/verimaker/opench-ch32v307
https://verimake.com/d/37-opench-ch32v307-risc-v

Yes, the docs are in chinese, and some links do not work.
You can login on gitee using a github account.

There is a youtube playlist about this board:
https://www.youtube.com/playlist?list=PL5k6lPIGwPvQ5SrKA6NajEQSRbbhgoJLg

The CH32V307 is supported by RT-Thread:
https://www.rt-thread.io

[SiliconWizard]

Digging up this thread as I've just ordered a couple dev boards for the CH32V307.
It has an impressive set of features for a $3 (per 1) chip, I particularly like having USB 2.0 HS and Ethernet at this price point. It's in stock at LCSC, although the stock levels are not very high, so wondering what happens if you need a few thousands of them? Does WCH sell directly?

Has anyone done anything significant with this MCU in the meantime? What about GCC now? (And OpenOCD?)

[brucehoult]

WCH sells directly and are very responsive both at @patrick_riscv (Technical Director) on twitter (see his bio for other contacts) and by email etc.

Their flashing/debug protocol is documented and a modified OpenOCD is on github.

It uses standard GCC or LLVM with the sole exception of their gcc knowing how to make the correct interrupt handlers for their "fast interrupt" mode -- an on-chip shadow register stack for a0-a7,t0-t6,ra on the 307, save to stack on the 003 (software transparent).  You can fake that up in regular GCC/LLVM with the overhead of a 2-instruction inline asm function that calls the actual handler.

Code: [Select]

__attribute__((naked))
void my_handler_wrapper(){
    asm volatile ("call my_handler; mret");
}

You write my_handler() as a normal C function.

[martinribelotta]

It uses standard GCC or LLVM with the sole exception of their gccknowing how to make the correct interrupt handlers for their "fast interrupt" mode -- an on-chip shadow register stack for a0-a8,t0-t7 on the 307, save to stack on the 003 (software transparent).  You can fake that up in regular GCC with the overhead of a 2-instruction inline asm function that calls the actual handler.

Code: [Select]
__attribute__((naked))
void my_handler_wrapper(){
    asm volatile ("call my_handler; mret");
}

You write my_handler() as a normal C function.

Be careful with it. This trick is only valid if you do not use FPU. The shadow stack is only for X registers in psABI... if you use FPU, the F0..31 is not saved by interrupt. Same carer if you use another abi that not follow the psABI specifications.

You can see a brief distuccion about it here:
https://github.com/hydrausb3/riscv-none-elf-gcc-xpack/issues/5

The user mengfanyuc@github (https://github.com/mengfanyuc) was create a patch for original xpack-riscv-none-elf to handle correctly the interrupt situation:
https://github.com/mengfanyuc/riscv-none-elf-gcc-xpack/commit/59ee16df7b6bf5ebbfa881a79f61dcf67eadb8e9

A definitive solution about vendor-specific interrupt management sould be the "prestacked annotation" in draft for revision:
https://github.com/jnk0le/riscv-total-embedded/blob/master/riscv-total-embedded.adoc#151-prestacked-annotation

[SiliconWizard]

This interrupt thing is the thing I was meaning to investigate, as I want to be able to use mainline GCC. So, thanks for the pointers.

Regarding the code Bruce posted: wouldn't just that work (neglecting the FPU thing):

Code: [Select]

__attribute__((interrupt, naked))
I've used the 'interrupt' attribute (without 'naked') for my RISC-V core which does emit 'mret', so no need to add it in assembly. But is the 'naked' attribute maybe incompatible with 'interrupt'?
Edit: answering my own question after a quick test, yes, they are unfortunately incompatible with each other.

The solution provided by Bruce is detailed here: https://blog.dan.drown.org/ch32v307-dev-board-part-2/
Note that while it works, it's slightly slower since it has to make an additional branch.

[brucehoult]

__attribute__((interrupt)) causes the compiler to use mret instead of ret and also to save only and exactly what registers it uses if you don't call any other function, or a0-a7,t0-t6,ra if you call any normal C function from the handler. It it for normal RISC-V interrupts (which WCH does by default).

But if you enable their "HPE" feature then a0-a7,t0-t6,ra are already saved for you in 1 cycle (on 307) by duplicate hardware registers, so saving them yourself is a waste of time.

__attribute__((naked)) makes the compiler not save ANY registers, not make any stack frame, not emit any ret etc ... only and precisely code for what you actually write. It's very dangerous.

[brucehoult]

Be careful with it. This trick is only valid if you do not use FPU. The shadow stack is only for X registers in psABI... if you use FPU, the F0..31 is not saved by interrupt.

Good point. I've only used it on chips without FPU. It would also be a pretty unusual interrupt handler that used FP.

But if you do ... then you need to save f0-7,f10-17,f28-31 yourself before calling arbitrary C code.

At that point the benefit from HPE is getting pretty marginal -- it's only saving 44% of the needed registers or 28% of the bytes if you have RV32 with a DP FPU (307 is SP) -- so you might as well just use standard RISC-V interrupts.

[SiliconWizard]

__attribute__((interrupt)) causes the compiler to use mret instead of ret and also to save only and exactly what registers it uses if you don't call any other function, or a0-a7,t0-t6,ra if you call any normal C function from the handler. It it for normal RISC-V interrupts (which WCH does by default).

Yep. With a small caveat, that you can check easily for yourself.
GCC will save *only* the registers the 'interrupt' attributed function uses... if you enable optimizations, from -O1 to -O3. With no optimization (probably expected), or (something that probably can bite many people here OTOH) with -Os, it does save ALL registers. I currently use GCC 13.2, but I checked that it has this behavior back to GCC 10.2. I didn't go further back than this, so dunno about earlier versions yet. Compile with '-Os', and bang, the whole set of registers is saved. Nasty if you ask me.

So for the article I posted above, the optimization level was likely set at -Os. If it was set at -O1 or above, there wouldn't be any difference in code between both variants of the code, as far as I can tell.

But if you enable their "HPE" feature then a0-a7,t0-t6,ra are already saved for you in 1 cycle (on 307) by duplicate hardware registers, so saving them yourself is a waste of time.

Yes, but how do you enable their HPE feature with mainline GCC?

__attribute__((naked)) makes the compiler not save ANY registers, not make any stack frame, not emit any ret etc ... only and precisely code for what you actually write. It's very dangerous.

Yep. But the function you call inside the 'naked' interrupt handler will itself save the registers it uses, so what do you gain compared to just using the 'interrupt' attribute and writing your code directly inside of it?
As long as you don't use '-Os', see my point above as well. (Again, nasty one, as '-Os' is a relatively "popular" opt. flag for embedded stuff.)
What am I missing here?

[martinribelotta]

At that point the benefit from HPE is getting pretty marginal -- it's only saving 44% of the needed registers or 28% of the bytes if you have RV32 with a DP FPU (307 is SP) -- so you might as well just use standard RISC-V interrupts.

For this reason, the best way to do interrupts is the IPRA optimization (inter procedural register allocation) that is present only in last LLVM versions (not gcc for now)

If you mark function with __attribute__((interrupt)) the compiler only view in the current function (or inlined functions) for the current compilation unit.

When IPRA is enabled, the resiger allocation optimizer can view across function call at link time. At least, for static binaries (mostly in embedded area).

The HPE techniques includes dedicated caches with big access word (like TriCore stack memory) and is not uncommon in DSP and onther FPGA/ASIC based implementations.
The idea of prestacked-annotation is fully flexible and cover many implementations. I hope that will be accepted in mainstream risc-v soon

[brucehoult]

__attribute__((interrupt)) causes the compiler to use mret instead of ret and also to save only and exactly what registers it uses if you don't call any other function, or a0-a7,t0-t6,ra if you call any normal C function from the handler. It it for normal RISC-V interrupts (which WCH does by default).

Yep. With a small caveat, that you can check easily for yourself.
GCC will save *only* the registers the 'interrupt' attributed function uses... if you enable optimizations, from -O1 to -O3. With no optimization (probably expected), or (something that probably can bite many people here OTOH) with -Os, it does save ALL registers. I currently use GCC 13.2, but I checked that it has this behavior back to GCC 10.2. I didn't go further back than this, so dunno about earlier versions yet. Compile with '-Os', and bang, the whole set of registers is saved. Nasty if you ask me.

I have no idea what you're on about here. Seems to me -Os works fine, and even -O0 is relatively sensible.

https://godbolt.org/z/GdcoxPfWf

But if you enable their "HPE" feature then a0-a7,t0-t6,ra are already saved for you in 1 cycle (on 307) by duplicate hardware registers, so saving them yourself is a waste of time.

Yes, but how do you enable their HPE feature with mainline GCC?

By fiddling the right bits in the right CSR? I don't have it to hand, but easy enough to find in the QingKe V4F manual.

__attribute__((naked)) makes the compiler not save ANY registers, not make any stack frame, not emit any ret etc ... only and precisely code for what you actually write. It's very dangerous.

Yep. But the function you call inside the 'naked' interrupt handler will itself save the registers it uses, so what do you gain compared to just using the 'interrupt' attribute and writing your code directly inside of it?

The standard C function you call inside the 'naked' interrupt handler will save, as usual, ONLY whatever of s0-s11,ra it uses.

It will blithely overwrite a0-a7,t0-t6 which will make whatever code was interrupted not very happy after you return from the interrupt if HPE is not enabled.

HPE instantly saves and restores a0-a7,t0-t6,ra for you.

If you are writing a small self-contained interrupt function (like in my godbolt example above) then __attribute__((interrupt)) is fine and will be only very slightly slower than HPE -- or even faster on the 003 which saves/restores to stack.

If your interrupt handler calls any standard C function then an __attribute__((interrupt)) handler will manually save/restore all of a0-a7,t0-t6.

[uer166]

I was mildly interested in RISC-V until I dug a little deeper and realized how much of a pain in the a$$ the nester interrupt handling is on RISC-V. The ARM NVIC "just works" without drama, this seems like you have to bend over backwards to achieve a similar result with ASM or compiler fuckery..

[martinribelotta]

I was mildly interested in RISC-V until I dug a little deeper and realized how much of a pain in the a$$ the nester interrupt handling is on RISC-V. The ARM NVIC "just works" without drama, this seems like you have to bend over backwards to achieve a similar result with ASM or compiler fuckery..

Is the same in any processor... interrupts is a mess... ARM created bad habits for us by giving us the NVIC in such a transparent way. The big problem os NVIC is the latency... any interrupt need a fixed amount of clocks and is not posible any optimization... Because this, the cortex-R line uses a more common vectored interrupt handling with IRQ and FIQ signals and software-based stack management.

[SiliconWizard]

__attribute__((interrupt)) causes the compiler to use mret instead of ret and also to save only and exactly what registers it uses if you don't call any other function, or a0-a7,t0-t6,ra if you call any normal C function from the handler. It it for normal RISC-V interrupts (which WCH does by default).

Yep. With a small caveat, that you can check easily for yourself.
GCC will save *only* the registers the 'interrupt' attributed function uses... if you enable optimizations, from -O1 to -O3. With no optimization (probably expected), or (something that probably can bite many people here OTOH) with -Os, it does save ALL registers. I currently use GCC 13.2, but I checked that it has this behavior back to GCC 10.2. I didn't go further back than this, so dunno about earlier versions yet. Compile with '-Os', and bang, the whole set of registers is saved. Nasty if you ask me.

I have no idea what you're on about here. Seems to me -Os works fine, and even -O0 is relatively sensible.

https://godbolt.org/z/GdcoxPfWf

I had to extract the minimal code that was leading to what I saw, to understand where it came from exactly. The piece of code I was trying with godbolt.org contained several functions to test various approaches for ISRs rather than just one.
I'm posting here the minimal code that triggers it with only '-Os',  actually not at '-O0' or any other level.

Code: [Select]

static volatile int n;

void Inc(void)
{
n++;
}

void __attribute__((interrupt)) MyISR2_Handler(void)
{
n++;
}

The reason I had this Inc() function was to test calling it from a naked function as you showed. But removing this naked function calling it (with an assembly call) doesn't change a thing in the behavior, so removed it for a minimal test case.

The reason only '-Os' triggers this odd behavior is that GCC will "aggressively" factor all code it can (while OTOH '-O3' tends to aggressively inline as much as it can.)
So if you look at the generated assembly, MyISR2_Handler() does call Inc() instead of having the "n++" statement inlined. Yes, pretty much the opposite behavior as you'd seen with '-O3' inlining almost every call of a function that is in sight.

And while calling Inc(), it doesn't consider any context of what Inc() does (I suppose), so it just saves all registers just in case. This is what I'd call a nice "bug". I have a knack for finding those.

Long story short here, regardless of ISRs or anything else, be careful about '-Os' as it may transform inline code as function calls. You may argue that it would mean that you have duplicated code (duplicated enough for GCC to do this), but when the duplicaiton is just one statement, that is frankly as odd as it can be counter-productive.

But if you enable their "HPE" feature then a0-a7,t0-t6,ra are already saved for you in 1 cycle (on 307) by duplicate hardware registers, so saving them yourself is a waste of time.

Yes, but how do you enable their HPE feature with mainline GCC?

By fiddling the right bits in the right CSR? I don't have it to hand, but easy enough to find in the QingKe V4F manual.

Yes maybe, or maybe it doesn't need anything enabled and it is by default? Didn't check either, but that was not my question. My point is that we still have no way with mainline GCC to have it NOT save registers in an ISR at all if the code is going to use some of them. Calling a function from a 'naked' function as shown above doesn't solve that. The called function will still save the registers it uses, while normally the HPE feature would avoid it altogether.

__attribute__((naked)) makes the compiler not save ANY registers, not make any stack frame, not emit any ret etc ... only and precisely code for what you actually write. It's very dangerous.

Yep. But the function you call inside the 'naked' interrupt handler will itself save the registers it uses, so what do you gain compared to just using the 'interrupt' attribute and writing your code directly inside of it?

The standard C function you call inside the 'naked' interrupt handler will save, as usual, ONLY whatever of s0-s11,ra it uses.

Yes, just like the 'interrupt' attribute does (when we don't run into this odd '-Os' bug)?
So I still don't get the benefit of using a 'naked' function call another function rather than directly use the interrupt attribute, which will achieve the same (when all goes well)?

[uer166]

any interrupt need a fixed amount of clocks and is not posible any optimization...

That is complete news to me. I've never had to have a defined (by clock cycle) ISR latency for any system (even high frequency control loop DSMPS). I mean it's nice, but clocks don't matter, absolute time does.

[brucehoult]

I was mildly interested in RISC-V until I dug a little deeper and realized how much of a pain in the a$$ the nester interrupt handling is on RISC-V. The ARM NVIC "just works" without drama, this seems like you have to bend over backwards to achieve a similar result with ASM or compiler fuckery..

As you wish, but NVIC is a lot of hardware that can be emulated -- nested interrupts, chained interrupts (i.e. without restoring and re-saving registers), servicing a higher priority interrupt that arrives while registers are being stacked -- with a few dozen instructions top level interrupt handler that has been worked out, published [1] and is not significantly slower than the "hardware" mechanism on CM0, CM3/4, CM7.

It's a slightly more RISCy DIY approach, but just as effective and NBD for pros. Certainly ARMv7-M makes things simple for beginners, but it comes at a cost. You can get into and out of simple RISC-V handlers (e.g. increment a global, or read a byte and insert into a buffer) faster than with ARM's heavyweight non-optional mechanism.

[1] https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#111-c-abi-trampoline-code

[SiliconWizard]

I was mildly interested in RISC-V until I dug a little deeper and realized how much of a pain in the a$$ the nester interrupt handling is on RISC-V. The ARM NVIC "just works" without drama, this seems like you have to bend over backwards to achieve a similar result with ASM or compiler fuckery..

Is the same in any processor... interrupts is a mess...

RISC-V is by nature a modular ISA, so while it's great from a number of POVs, it obviously leads to fragmentation.
Interrupts were defined in a very basic way in the RISC-V specs, so that almost if not all companies creating products have implemented their own interrupt controller. The RISC-V PLIC spec was ratified much later on, and even if it's a reasonable interrupt controller, even new CPU/MCU designs will come up with a different interrupt controller than the RISC-V PLIC, or add various extensions to it, thus in turn often requiring specific additions to the compilers.

That may all converge over time, but I still don't know how it'll turn out.

ARM created bad habits for us by giving us the NVIC in such a transparent way. The big problem os NVIC is the latency... any interrupt need a fixed amount of clocks and is not posible any optimization... Because this, the cortex-R line uses a more common vectored interrupt handling with IRQ and FIQ signals and software-based stack management.

Well, it's a bit like comparing Linux and macOS. ARM is a closed approach, it just works but you get what they give you and nothing more.

[brucehoult]

__attribute__((interrupt)) causes the compiler to use mret instead of ret and also to save only and exactly what registers it uses if you don't call any other function, or a0-a7,t0-t6,ra if you call any normal C function from the handler. It it for normal RISC-V interrupts (which WCH does by default).

Yep. With a small caveat, that you can check easily for yourself.
GCC will save *only* the registers the 'interrupt' attributed function uses... if you enable optimizations, from -O1 to -O3. With no optimization (probably expected), or (something that probably can bite many people here OTOH) with -Os, it does save ALL registers. I currently use GCC 13.2, but I checked that it has this behavior back to GCC 10.2. I didn't go further back than this, so dunno about earlier versions yet. Compile with '-Os', and bang, the whole set of registers is saved. Nasty if you ask me.

I have no idea what you're on about here. Seems to me -Os works fine, and even -O0 is relatively sensible.

https://godbolt.org/z/GdcoxPfWf

I had to extract the minimal code that was leading to what I saw, to understand where it came from exactly. The piece of code I was trying with godbolt.org contained several functions to test various approaches for ISRs rather than just one.
I'm posting here the minimal code that triggers it with only '-Os',  actually not at '-O0' or any other level.

Code: [Select]

static volatile int n;

void Inc(void)
{
n++;
}

void __attribute__((interrupt)) MyISR2_Handler(void)
{
n++;
}


Ugh! Certainly a bug, as it causes huge code expansion, sontrary to the expressed intent of -Os

"static" on Inc() fixes it.  Also Clang is fine.

But if you enable their "HPE" feature then a0-a7,t0-t6,ra are already saved for you in 1 cycle (on 307) by duplicate hardware registers, so saving them yourself is a waste of time.

Yes, but how do you enable their HPE feature with mainline GCC?

By fiddling the right bits in the right CSR? I don't have it to hand, but easy enough to find in the QingKe V4F manual.

Yes maybe, or maybe it doesn't need anything enabled and it is by default?

Certainly not! That would break all standard RISC-V code.

My point is that we still have no way with mainline GCC to have it NOT save registers in an ISR at all if the code is going to use some of them. Calling a function from a 'naked' function as shown above doesn't solve that. The called function will still save the registers it uses, while normally the HPE feature would avoid it altogether.

NO!

With HPE the called wrapped standard C function will freely use a0-a7,t0-t6 -- that's up to 15 registers -- WITHOUT saving them. It will only make a stack frame and save some of s0-s11 if it calls some other C function or needs more than 15 live variables.

An __attribute__((interrupt)) function will save every register it uses, right from the first one.

[SiliconWizard]

With HPE the called wrapped standard C function will freely use a0-a7,t0-t6 -- that's up to 15 registers -- WITHOUT saving them. It will only make a stack frame and save some of s0-s11 if it calls some other C function or needs more than 15 live variables.

An __attribute__((interrupt)) function will save every register it uses, right from the first one.

Ok, I had to try a representative example to see exactly how GCC would handle the difference (and I used -O2 just to not have any potential quirkness of -Os which would not be relevant here).
https://godbolt.org/z/qdc4je3bE

So yeah, I see. If calling an external function (which I commented out here), that gets much worse of course.

Now whether the additional call/ret will add more cycles than saving a couple registers (in the simplest cases) is yet to be seen. But if you call any external function, the difference will certainly be significant.

Note: to enable HPE, set the HWSTKEN bit of the INTSYSCR CSR to 1 - the reset value is indeed 0. I've looked at their SDK. It's so-so. There is no definition for most CSRs that I could find, they use hard-coded values almost everywhere they use CSRs. Yuck. They enable the nested and hardware stacks for instance in their provided startup code: startup_ch32v30x_D8.S.

Code: [Select]

li t0, 0x0b
csrw 0x804, t00x0b = 0b1011 => that's PMTCFG set to "4 levels of nesting, with 2 preemption bits", Interrupt nesting enabled and HPE enabled.

So if you don't want it enabled, don't use their startup code or modify it.
CSRs are documented in the "QingKeV4 Microprocessor Manual".

[jnk0le]

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

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

[ddrown]

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.

In case you're interested, I took wch's USB high speed (480M) serial example and made some modifications. I have a blog post with more info on my goals, but if you just want the code it's at https://github.com/ddrown/usbhs-cdc

[tellurium]

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

Would you be willing to share that GCC + makefile setup ?

That chip has Ethernet MAC and PHY onboard, which is begging for a baremetal webserver example, which we're willing to invest into.
But... 64k RAM and 256k flash only? How practical is having networking on that device.
OTA support needs 2x flash space, cutting 256k down to 128k, making the whole effort not really feasible.

[wilhe_jo]

Wch has a Webserver example on their GitHub already.

You can also configure the SRAM size... Seems they copy serial flash to SRAM and execute from there...

4MB SRAM is very, very cheap... So no problems with ota updating.

73

[mikeselectricstuff]

Wch has a Webserver example on their GitHub already.

You can also configure the SRAM size... Seems they copy serial flash to SRAM and execute from there...

4MB SRAM is very, very cheap... So no problems with ota updating.

73

..I assume you mean SPI flash - yes, crazy cheap - like under ten cents in small qtys at lcsc

[wilhe_jo]

Ahhh, yes ... SPI flash...

Jlcpcb even has one as a basic part... So no even no fee for pcba.
Pretty crazy.

73

[ddrown]

Would you be willing to share that GCC + makefile setup ?

That chip has Ethernet MAC and PHY onboard, which is begging for a baremetal webserver example, which we're willing to invest into.
But... 64k RAM and 256k flash only? How practical is having networking on that device.
OTA support needs 2x flash space, cutting 256k down to 128k, making the whole effort not really feasible.

I've converted a few wch examples to gcc + makefile

https://github.com/ddrown/CH32V307-makefile-example

And I have the base lwip too https://github.com/ddrown/ch32v307-lwip

[wilhe_jo]

Hey, that's interesting!

The "official" binary library is pretty annoying...
But I didn't bother to investigate how much effort it would be to port lwip or uip on my own.

Anyhow, that IC is relatively easy to work with...even though the documentation is basic and the software samples contain quite some chinglish comments...

73

[jnk0le]

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.

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.
https://github.com/jnk0le/openocd-wch/commit/a82b7041570ed1495b48f2cca8706197cbc160cb#diff-434682464f8ddc4ea0f0cc856a6c8690edc056d4d46594f9e1a92cc7be262535R1079

 I'm also hosting windows builds from gpl lettered sources of their fork here: https://github.com/jnk0le/openocd-wch/releases

[ali_asadzadeh]

Has anyone done ModBUS TCP on this beauty?

[bingo600]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

[wilhe_jo]

I use this WCH 32v307 dev-board you can get eg. from elektor (fastest/cheapest option back then).

This has a wch-link that can be separated (it has jumpers if you don't want to snap it apart).
Never had any issues with it under linux... same with their Eclipse based IDE...

73

[tellurium]

Baremetal Makefile project for ch32v307 with Mongoose library is ready and working:  https://github.com/cesanta/mongoose/tree/master/examples/wch/ch32v307-make-baremetal-builtin

Some facts:
1. The firmware code (not counting toolchain/sdk files), is only 5 files including headers
2. Mongoose implements the whole networking engine (drivers, TCP/IP stack, HTTP/Websocket/MQTT/SNTP.. lib) in a single file
3. In main.c, all network-related code that sets up ethernet, TCP/IP, and implements a web server, is ~20 lines
4. The most amazing thing is that the driver for CH32V307 is ... the ST driver for F4/F7 series! Works with no changes. They use the same MAC controller as ST chips do. Even the address of the MAC controller is the same, 0x40028000 !


Steps to build & try (on Mac, Windows, Linux):
1. Setup build environment: https://mongoose.ws/documentation/tutorials/tools/ , most notably - symlink support for git & make
2. Install riscv toolchain, e.g. on Mac `brew install riscv-gnu-toolchain`
3. clone mongoose repo: git clone https://github.com/cesanta/mongoose/
4. Go to examples/wch/ch32v307-make-baremetal-builtin, start command prompt/terminal, run "make"
5. Attach serial console to USART1: TX pin A9. Use serial converter
6. Observe logs, look at the obtained IP address (see below for logs example)
7. Point your browser at that IP address


412    2 net_builtin.c:197:onstatechang READY, IP: 192.168.2.78
417    2 net_builtin.c:198:onstatechang        GW: 192.168.2.1
41d    2 net_builtin.c:199:onstatechang       MAC: 02:38:9a:a3:39:e3
423    2 main.c:107:main                Initialising application...
429    3 net.c:195:mg_listen            1 0 http://0.0.0.0
42e    2 main.c:110:main                Starting event loop
7dd    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:4, tx:3, dr:0, er:0
bc5    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0
fad    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0

[brucehoult]

Baremetal Makefile project for ch32v307 with Mongoose library is ready and working: 

Nice!

How is the code size?

[tellurium]

How is the code size?

Around 46k on flash


-rwxr-xr-x  1 cpq  staff   47220 22 Nov 04:36 firmware.bin 


RAM footprint:
1. Driver DMA descriptors: 1540 * NUM * 2. NUM is 4 currently, total 12320 bytes
2. Send buffer 1540 bytes
3. Receive queue 8k
4. Per-connection buffers, allocation granularity is tunable as MG_IO_SIZE (default 2048), so let's say 4k per connection.

There is no intermediate BSD socket layer, no intermediate tasks to pass data - so that's pretty much all usage

Summary:
  a) TCP/IP stack eats about 20k of RAM (can be tuned down twice the size, down to 10k)
  b) each connection eats about 4k (can be tuned down to ~1k per connection). Mongoose shapes traffic for file requests, so even downloading a huge file won't increase connection's RAM usage.

Integrating a full device dashboard like this https://mongoose.ws/device-dashboard/ would take:
a) Copying extra 3 files to the source tree
b) Increase on flash footprint ~50k

[SiliconWizard]

How does it compare to lwIP?

[ali_asadzadeh]

Baremetal Makefile project for ch32v307 with Mongoose library is ready and working:

Thanks for sharing, does you lib support modbus too?

[SiliconWizard]

I've done more testing - not the Ethernet peripheral yet.

The ADC, for instance. The docs say that the ADC clock should not exceed 14 MHz - since it has a 1:8 prescaler at most, that means a corresponding PCLK clock of max 112 MHz. I've tested it with a PCLK clock of 144 MHz and didn't notice any significant difference in performance. Obviously the max sampling time is going to be shorter, so you should take that into account.

Another thing: the I2C peripheral is specified for a max PCLK clock of 60 MHz as far as I can tell. There is no further prescaler between PCLK and the I2C peripheral. Experimenting will tell whether using a higher freq PCLK will work, and how.
I2C is not particularly well documented on this chip in general. The way it's implemented is a bit odd. Also, the divider to get a specific SCL frequency is not documented either. Looking at the source code for I2C in the SDK, they use several cases depending on frequency with different factors, that we don't know where they come from. In their provided examples, there's also no example at all (AFAICT) that handles the ACK response of a slave properly. So any practical implementation will require writing your own driver (which is not a bad thing, just don't rely on the SDK too much.)

I've tested USB HS with TinyUSB, works fine. (TinyUSB has quirks of its own with some USB classes, but that's beyond the port to the CH32V307, although I was not able to make any UAC2 class work with it, but hadn't tested UAC2 with TinyUSB before, so that may or may not be specific.)

Another thing I plan on testing after Ethernet is memory protection. And, overclocking the core - haven't yet checkd if it's even possible to generate over 144 MHz with the PLL, I guess it should be.)

[tellurium]

How does it compare to lwIP?

That is a difficult question to answer, let me try.
First of, lwip has 3 APIs: raw callback-based, netconn, and socket.
Depending on an API, the architecture of the whole stack is different.

The raw API handles frames in the same task: driver -> stack -> application, and data is passed via a direct function call.
This is also how Mongoose stack works. This is the fastest architecture in terms of performance. I won't cover LWIP netconn here: it is a "connection abstraction" built on top of raw lwip, very much like Mongoose, which also has a "struct mg_connection" abstraction.

The socket API organises frame handling differently. TCP/IP stack and user app run in different RTOS tasks, and data is passed not via direct function calls, but via a RTOS queue. This makes an implementation slower in comparison to the "raw callback" one, but on the other hand it allows blocking send()/recv() calls. A user app task can block whilst not blocking the driver or stack. Also, a typical lwip firmware runs a separate task to sense PHY status.

Socket layer organises it's own data buffering, to allow app to read data long time after it was received. Data gets buffered by each socket's send/recv buffers, and application has its own buffers. Mongoose built-in stack does not use sockets API, thus it does not have that intermediate buffering - as well as raw LWIP. That means that socket-based implementations are more memory hungry than non-socket. So, socket-based frame handling looks like this:
driver (queue)--> stack + socket buffers task (queue)--> application task

I've done a performance benchmark 6-7 months ago, comparing several implementations for fetching a simple "hello world" page, using "siege" benchmarking tool:siege -c 5 -t 5s http://IP. LWIP config was a default Cube one. All tests were done on a Nucleo-F746ZG, connected to an Ethernet dongle to the same workstation that ran the benchmark - so absolute numbers do not matter, what matters is relative difference.


                       Zephyr      LWIP sockets     LWIP raw    Mongoose
Requests per second    3           16               286         1080
Firmware size          117k        160k             114k        28k


I don't know why zephyr shows so bad there - maybe something was missing, I just don't believe 3 QPS.  LWIP's httpd server was used for the benchmark.

In terms of memory usage, I've shown Mongoose numbers above. LWIP has its own memory manager, and it could be configured to be very efficient with DMA descriptors, so overall I expect that raw LWIP can be configured less RAM hungry as Mongoose. I expect socket-based LWIP to be more memory hungry. Again, that all depends on a specific LWIP config.

[tellurium]

Thanks for sharing, does you lib support modbus too?

The answer is "partially yes".

Mongoose can do raw TCP, so whatever protocol is used on top - like modbus, you can handle "manually": receive data over TCP, and parse modbus manually.  Likewise, for send path, you can craft modbus packets and send them over TCP.

Currently, Mongoose does not have a built-in modbus protocol parser. Shall we add it? Could you share a practical use case please?

[ali_asadzadeh]

Currently, Mongoose does not have a built-in modbus protocol parser. Shall we add it? Could you share a practical use case please?

It would help a lot, since the ch32v307  is the very cheap, and it can be used in almost many industrial products that need modbus communication, for example a a data collector or data loger with modbus tcp.

[SiliconWizard]

                       Zephyr      LWIP sockets     LWIP raw    Mongoose
Requests per second    3           16               286         1080
Firmware size          117k        160k             114k        28k

Thanks, those results look pretty impressive. Basically a no-brainer. What's the catch with Mongoose if any?

[SiliconWizard]

Just a note regarding the official SDK for the CH32V3xx, that can be found here: https://github.com/openwch/ch32v307

There's a version of it in the "C++/Use MRS Create C++ project-example/CH32V307VCT6" subdirectory. And then there's another (newer) version of it in the "/EVT/EXAM/SRC" subdirectory. A bit of a mess to find out where the SDK really is and which is the latest version. Cleaning things up could be a nice touch.

Apart from this bit of a "mess", one thing is slightly more concerning. While the license mentioned in all SDK files in the former directory above is Apache 2.0, in the more recent version in the latter directory above, they have removed the Apache 2.0 license mention and replaced it with a mention that the files should be used only with WCH products. Yeah.

Of course you can write your own support files instead, if you have some time to invest. But as it is, it becomes unclear under which license exactly the files are released.

[jnk0le]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

I think its not persistent.

One more thing you could try is minichlink https://github.com/cnlohr/ch32v003fun/tree/master/minichlink, not sure how it handles this button less module.

[bingo600]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

I think its not persistent.

One more thing you could try is minichlink https://github.com/cnlohr/ch32v003fun/tree/master/minichlink, not sure how it handles this button less module.

That's the one i (ddrown) used , and it's complaining about the mode of the buttonless wchlink , but works fine with the wchlink-e

/Bingo

[tellurium]

Thanks, those results look pretty impressive. Basically a no-brainer. What's the catch with Mongoose if any?

Here's the catch:
Mongoose is dual licensed - GPLv2 / commercial. If your project is free, Mongoose is free for you. If you're making money using Mongoose, then it is not free (unless you comply with GPLv2 and open your sources). I am the original author of Mongoose, started working on it in 2004.

My company works on Mongoose full time, and selling licenses is our business model. Marketing plug: our customers are very diverse: starting from sole freelancers (license price is affordable for them), ending with big names like Bosch, Siemens, etc. Mongoose is run by NASA on International Space Station, serving results of scientific experiments in real time (before, they were physically shipping hard drives to Earth). </End -Of-Marketing-Plug>

I am obviously biased, but convinced that Mongoose is the best embedded network lib on the market.

Now, we started to make a modbus dashboard, the plan is to turn ch32v307 into an easy to use modbus-tcp master. Maybe not just TCP, but also a serial, serving both serial and Ethernet slaves, and providing Web UI dashboard. If anyone has strong opinions / suggestions, please PM me, or start a separate thread. The goal here is to create a simple, usable, open-source modbus master which can work on any chip with network (and by using modules like W5500, it is pretty much, any chip).

[ali_asadzadeh]

tellurium thanks for sharing, Please add instruction on installing the compiler and debugger tool on win11 for ch32v307 in your website or here.

[bingo600]

tellurium thanks for sharing, Please add instruction on installing the compiler and debugger tool on win11 for ch32v307 in your website or here.

I found , that compiler inst. were documented here (ARM) ... So just replace "compiler inst w. Risc-V
https://mongoose.ws/documentation/tutorials/tools/

Riscv Compiler   (I would do the manual install)
https://xpack.github.io/dev-tools/riscv-none-elf-gcc/

https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/

I just had to replace the compiler + objcopy "exe name" in the makefile
Using linux.

[wilhe_jo]

Well, the CH32 have another great feature: high-speed usb PHY on chip!

Sofar TinyUSB got me to something working pretty quickly.

The IDE package provided by WCH also runs relatively smooth...

73

[tellurium]

Well, the CH32 have another great feature: high-speed usb PHY on chip!

Again this makes me wonder - why they put so little RAM / flash on that chip, considering high speed Ethernet and USB peripherals?
Is that because this is a "testing" chip, and WCH plans to release a "big brother" of CH32V307 soon?

[wilhe_jo]

Well, for quite some applications, the memory is not really a big problem.

If you think the ch32v307 seems odd, look at this one: CH569

ATM, I design a usb RF power sensor where all the calibration stuff etc is handled on the pc.
For such applications (ie data processing is handled on the pc), this is quite a nice fit.

73

[SiliconWizard]

Well, the CH32 have another great feature: high-speed usb PHY on chip!

Again this makes me wonder - why they put so little RAM / flash on that chip, considering high speed Ethernet and USB peripherals?
Is that because this is a "testing" chip, and WCH plans to release a "big brother" of CH32V307 soon?

It's not that little. And this is meant to be cheap. You can't have it all. But yes they're probably going to expand the family.

Note that, as I explained earlier, its RAM/Flash availability is a bit odd and not very clearly documented.
It actually has 128 KB of RAM and 288 KB of flash.
But the catch is that some of the RAM can be used to cache some of the flash (in a non-documented way, at least AFAICT), so that the more RAM you have available, and the less flash. It's configurable through option bytes, from 32 KB RAM/288 KB flash to 128 KB RAM/192 KB flash. It's probably not going to help much if you need at the same time more RAM and more flash, but something that's good to know nonetheless.

I get it that this is still a bit tight for a typical application using Ethernet (at least if you're going to use TCP/IP, otherwise that can be relatively lightweight), but for USB HS, not really. People are getting spoiled these days, or I don't know! Remember that for a good while before FTDI released their first USB HS chip and later on, more MCUs started to appear with USB HS, the almost only "cheap" solution you had was the Cypress FX2. And it only had 16 KB of RAM in total, for both code and data.

I'm actually glad to have USB HS in this "modest" MCU. USB HS is still relatively uncommon in MCUs in general and you usually have to resort to Cortex-M7 stuff, so the "top of the line" basically. And some Cortex-M4 stuff, most of which requring an external PHY. I have plenty of applications that can leverage USB HS without requiring a powerful MCU, and that gives us a good alternative to FTDI chips.

I wouldn't mind more RAM, but the amount it has can still be put to some good use. Same for flash. Some would probably like an external QSPI flash solution better, to have a lot more room, but that requires an external chip, usually takes a lot more time to boot, and is slower.

So, I'm not expecting to have an alternative to NXP iMXRT10xx with this, but it's still pretty cool. I'm starting to like it and already have a few projects in mind in which it would be a good fit.

[ali_asadzadeh]

Thanks for the update, I have followed the instruction with these

I opened the git bash in the wch project directory and typed like this

xpm init # Only at first use.
xpm install @xpack-dev-tools/riscv-none-elf-gcc@latest --verbose

It went ok

after install I have added  "C:\>%USERPROFILE%\AppData\Roaming\xPacks\@xpack-dev-tools\riscv-none-elf-gcc\13.2.0-2.1\.content\bin"  the to the windows path
now I can Use

riscv-none-elf-gcc --version

in git bash and it would print like this

riscv-none-elf-gcc.exe (xPack GNU RISC-V Embedded GCC x86_64) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Now when I tpye make in the wch project I would get this errors

make
riscv64-unknown-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
make: riscv64-unknown-elf-gcc: No such file or directory
make: *** [Makefile:25: firmware.elf] Error 127

I tried to modify the make file to this

Code: [Select]

CFLAGS = -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion
CFLAGS += -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion
CFLAGS += -ffunction-sections -fdata-sections #-fmessage-length=0 -fsigned-char
CFLAGS += -march=rv32imafc -mabi=ilp32f #-msmall-data-limit=8 -mno-save-restore
CFLAGS += -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os $(CFLAGS_EXTRA)

LDFLAGS = -T vendor/link.ld -nostartfiles --specs=nano.specs #--specs=nosys.specs
LDFLAGS += -lc -lgcc -Wl,--gc-sections #-Wl,-Map=$@.map

SOURCES = main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S

ifeq ($(OS),Windows_NT)
  RM = cmd /C del /Q /F /S
else
  RM = rm -rf
endif

all: firmware.bin

firmware.bin: firmware.elf
riscv-none-elf-objcopy -O binary $< $@
ls -l firmware.*

firmware.elf: $(SOURCES) hal.h Makefile
riscv-none-elf-gcc $(SOURCES) $(CFLAGS) $(LDFLAGS) -o $@

flash: firmware.bin
wchisp flash $<

clean:
$(RM) firmware.* *.su


and I get this error

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

[ali_asadzadeh]

If you think the ch32v307 seems odd, look at this one: CH569

Wch has come to destroy some ARM chips including STM32 with its insane prices!

[SiliconWizard]

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

I don't know what's the deal with this version of the compiler on Windows and why it's trying to create temporary files in C:\Windows - that sounds pretty bad. So maybe this compiler has been built with someone's feet, or you haven't properly installed it. Dunno. Normally GCC binaries don't need any specific installation, but this particular build may be different, may require some environment variables to be defined, whatnot.

One quick thing you can try before solving this compiler (probably installation) issue is to add the '-pipe' option to CFLAGS. It should normally prevent GCC from having to create temp files, so (if everything goes well, no hard guarantee here) that may solve your issue.

[martinribelotta]

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

This is produced by the unset TMP variable (gcc use a temporary files to store intermediate compilation artifacts like preprocessed code and assembler files)

https://community.infineon.com/t5/Wi-Fi-Combo/Fatal-toolchain-error/td-p/104592

The correct way to solve this is add to environment variables a system-wide temporary directory like C:\temp

[tellurium]

tellurium thanks for sharing, Please add instruction on installing the compiler and debugger tool on win11 for ch32v307 in your website or here. :-

I'll start a separate topic for ch32v307 modbus console, to avoid polluting this topic.

[SiliconWizard]

News of the day regarding my CH32V307 journey.

I've found (a bit) more info about the RAM/Flash situation. Read it in a closed ticket in the openwch github issues. Apparently WCH still haven't released official documentation about it. Go figure. Maybe they want to reserve the possibility to change the memory architecture of the family at any point in the future, so they keep it quiet.

Anyway, for what we know, here goes (with a bit of conditional as this is again not 100% official):

- It has a total of 320KB RAM and a total of 488KB Flash. (Yes, that much.)
- The seemingly "odd" available combinations mentioned earlier are in fact simple to understand once we know that: the total of the available Flash (for code) and available RAM (for data) is 320KB, the total amount of RAM. So all combinations from 32/288 to 128/192 are just that. Which seem to imply that *all* code from Flash is copied into RAM at boot, and executed from RAM. It would thus seem that the core is unable to directly execute code from its own internal Flash (and there doesn't seem to be caches nor programmable wait states anyway). That is not an uncommon situation for many lower-cost MCUs, especially from China. It's even very possible that the internal Flash is actually a separate die inside the package. Would be interesting to see the internals to confirm.
- What that also means is that even at the highest code size setting (288KB Flash), there would still be 200KB available Flash for read/write access for storing user data. It's undocumented, but relatively easy to test. The question is, is this available at the expected addresses? May be tough if we have no docs about that, we'll have to experiment.

Other than this, I was trying to use SPI in half-duplex mode, and while having some issues, since the RM was not very detailed about it, and since it's a known fact that they've copied a lot of ST material, I've looked at the RM of a STM32 MCU about the SPI peripheral to figure it out. Yes. And so I can also confirm that they've indeed copied a significant part of ST RM's. Even the bit fields of most registers have the same (or almost) names. Fun.

Speaking of SPI half-duplex, I found out that in master, half-duplex, in RX mode, the MCU starts clocking immediately as long as the peripheral is enabled and never stops clocking until we disable it. Which is relatively unpractical for many applications. Turns out the STM32 SPI does the same thing. I have yet to find a way of having it at least stop clocking exactly on words boundaries (to avoid "spurious" extra clock pulses.)

[wilhe_jo]

Well, if you try to decode the chinglish you could come up with the theory, that part of the flash is the bootloader, and that this bootloader could be modified.

However, if you ask, you get told you can't...

Anyhow my feeling is, that this is just not supported, and that it may be similar to the ch32v003....

In praxis, this would be a really useful feature.

73

[mikeselectricstuff]

News of the day regarding my CH32V307 journey.

I've found (a bit) more info about the RAM/Flash situation. Read it in a closed ticket in the openwch github issues. Apparently WCH still haven't released official documentation about it. Go figure. Maybe they want to reserve the possibility to change the memory architecture of the family at any point in the future, so they keep it quiet.

Anyway, for what we know, here goes (with a bit of conditional as this is again not 100% official):

- It has a total of 320KB RAM and a total of 488KB Flash. (Yes, that much.)
- The seemingly "odd" available combinations mentioned earlier are in fact simple to understand once we know that: the total of the available Flash (for code) and available RAM (for data) is 320KB, the total amount of RAM. So all combinations from 32/288 to 128/192 are just that. Which seem to imply that *all* code from Flash is copied into RAM at boot, and executed from RAM. It would thus seem that the core is unable to directly execute code from its own internal Flash (and there doesn't seem to be caches nor programmable wait states anyway). That is not an uncommon situation for many lower-cost MCUs, especially from China. It's even very possible that the internal Flash is actually a separate die inside the package. Would be interesting to see the internals to confirm.
- What that also means is that even at the highest code size setting (288KB Flash), there would still be 200KB available Flash for read/write access for storing user data. It's undocumented, but relatively easy to test. The question is, is this available at the expected addresses? May be tough if we have no docs about that, we'll have to experiment.

Other than this, I was trying to use SPI in half-duplex mode, and while having some issues, since the RM was not very detailed about it, and since it's a known fact that they've copied a lot of ST material, I've looked at the RM of a STM32 MCU about the SPI peripheral to figure it out. Yes. And so I can also confirm that they've indeed copied a significant part of ST RM's. Even the bit fields of most registers have the same (or almost) names. Fun.

Speaking of SPI half-duplex, I found out that in master, half-duplex, in RX mode, the MCU starts clocking immediately as long as the peripheral is enabled and never stops clocking until we disable it. Which is relatively unpractical for many applications. Turns out the STM32 SPI does the same thing. I have yet to find a way of having it at least stop clocking exactly on words boundaries (to avoid "spurious" extra clock pulses.)

If flash is on a seperate die, chances are it's SPI, so you may see differences in startup time depending on the memory configuration selected

[SiliconWizard]

After digging up a bit, some info can be found in the DS and RM about the memory layout, although they're not very verbose about it all.

From what I gathered on github and these documents, it now seems more than likely that they do copy all code in RAM at startup. They call that the "R0WAIT" area. The use of RAM is as I described above.
The Flash memory is 480KB in total and the "non-zero-wait" area follows the zero-wait area (where code is located). In the RM (p. 15), we can see the memory layout.

- Code memory is remapped at address 0 in normal boot mode (once it's been copied into RAM), it's the remapped location of code in RAM.
- The start of the RAM data area is mapped at address 0x2000_0000. Its size is 320KB - (max code size as set in config bytes), as I explained earlier.
- It's apparently not possible to have any other configuration than the ones listed earlier.
- The Flash itself is still accessible at address 0x0800_0000. The area above the max code size (at least 192KB and up to 288KB) should be freely available as read/write - I'll have a look at their SDK code for accessing Flash and will do some testing.
- The bootloader is stored in "system Flash", it's an area separated from the Flash described above. It's not part of it. It's 28KB and its address is 0x1FFF_8000. Whether it can be user written, testing will tell. (With caution of course as we could bork the bootloader.) There is a way of writing to it as they do it in production (which is not silly compared to using pure ROM). But maybe it requires some test pin (not broken out) to be asserted. Or maybe not. WCH doesn't seem to want to talk about it (as can be seen in some discussions), but testing that should be easy. Reading the entire bootloader (if possible) and saving it before attempting to write to this area is probably a good idea, just in case.

This bootloader arrangement probably explains why , from the two identical dev boards I have, one works fine with the USB ISP mode, and the other has issues with it. It's most likely not the same version of the bootloader on both chips.

As to the internal Flash being SPI, I sincerely doubt it. It's probably parallel Flash. According to the DS, the typical start time (that's documented in the wake-up time from standby) for a 256K code setting, including LDO and HSI clock stabilization, is 8.9 ms. There's no way it could be achieved through SPI unless running at clock speeds much higher than the chip could reasonably handle, and certainly not from the HSI clock that runs at startup.

[tellurium]

- It has a total of 320KB RAM and a total of 488KB Flash. (Yes, that much.)
- The seemingly "odd" available combinations mentioned earlier are in fact simple to understand once we know that: the total of the available Flash (for code) and available RAM (for data) is 320KB, the total amount of RAM. So all combinations from 32/288 to 128/192 are just that. Which seem to imply that *all* code from Flash is copied into RAM at boot, and executed from RAM. It would thus seem that the core is unable to directly execute code from its own internal Flash (and there doesn't seem to be caches nor programmable wait states anyway). That is not an uncommon situation for many lower-cost MCUs, especially from China. It's even very possible that the internal Flash is actually a separate die inside the package. Would be interesting to see the internals to confirm.

The board I have, has 32/288 configuration. In other words, it uses the config with the minumum RAM of 32k.
There is a snippet in the WCH's linker script:


/* CH32V30x_D8C - CH32V307VC-CH32V307WC-CH32V307RC
   CH32V30x_D8 - CH32V303VC-CH32V303RC
   FLASH + RAM supports the following configuration
   FLASH-192K + RAM-128K
   FLASH-224K + RAM-96K
   FLASH-256K + RAM-64K 
   FLASH-288K + RAM-32K 
*/
   FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 288K
   RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
}


Which means that by default, they configure for this minimal RAM configuration.

For Ethernet networking, 32k is a bit low, so both user option bytes (documented at RM 32.4.6 and 32.6) and linker script has to be modified. I assume, 96/224 should suffice.

About the extra flash.. That extra can be used for persistent storage, maybe even LittleFS can be adopted, since the flash page size is small (256 bytes), so LittleFS should be quite efficient there. Where is that extra flash ? Is it contiguous with the documented one, or reside on a different address?

[SiliconWizard]

Yes, for the linker script that's provided with their SDK, I talked about it in an earlier post. They have set a 32K/288K layout in it, but there are comments. Adapt it to your own settings.
Have you checked that the MCU on your board is configured for 32K/288K? The RM doesn't mention what the factory value is. It's marked "xxb". On my dev boards (which are third party, not WCH), the MCU comes set with the 64K/256K option.
You need to check it using your programming tool.

I've read more of the RM about Flash, and it's now not as clear whether the MCU can't execute code directly from Flash. Maybe it can. What happens when they shadow (copy) part of the Flash to RAM is that the core can fetch instructions at full clock speed up to 144 MHz. But the Flash can be only read at up to 60 MHz according to the docs, and the Flash controller is configured by default for HCLK/2, meaning accesses are made at half speed of HCLK (which is why they mention to be careful with Flash operations if HCLK exceeds 120 MHz.)

I've tested that all Flash could be read directly with a memory access at its documented address. But it's only data access. While I haven't tested it yet, it's possible that the core may be able to execute code directly from Flash (thus in the non-zero-wait area), possibly at half clock speed depending on the Flash controller config. That's something interesting to test for sure. That would mean that one could have a smaller fraction of code placed in the shadow RAM for code that needs fast execution, and still be able to run code up to 480K. Unless they have explicitely restricted that, it should be possible, as the addresses are completely consecutive. Should be interesting.

The whole 480K are consecutive and can be accessed as a whole, both for read and write operations. (Write operations require specific handling of course, while read operations are just simple memory accesses.)
There are a couple examples in the SDK that show this, like the 'MSC_U-Disk' example.

[SiliconWizard]

Note that even if the MCU can't execute code in the non-zero-wait area, it can freely *read* data from it. So we can always write a linker script that will put all (or not, possibly just some specific data) your constant data in this upper area, leaving the lower area (RAM-shadowed) for *code* only, and not for "expensive" constant data (can be especially cool if you use a lot of initializers, such as graphics, or other).

Cool stuff.

[iMo]

Afaik the first CH32F103 was dual chip with mcu chip and the spi flash chip on top, there are great die shots discussed here in past. I would guess the bootloader is hardwired in an on-chip "rom" (not a "flash" technology") and the mcu has only sram on its chip (320kB in your case). The SPI flash chip sitting on the top of the mcu chip could be 640kB or 1Mbyte large, imho (they use standard flash chips, my bet).

PS: it could be they did not master the flash technology on the same chip with the mcu yet, or they have issues with the flash access accelerators (ie the ART STM is using), etc., and in order to achieve the same performance they have to run everything in sram. Moreover the company started as their major SPI flash chips manufacturer there, thus mcus was/is their secondary biz, afaik..

[wilhe_jo]

I'm not really sure about the bootloader being hard coded.

Just read the DS and RM... I bet it's located in the same flash as the rest. My guess is, however, that access to this area is somewhat difficult/impossible due some design decision.

My guess is that there's a procedure like the option-byte programming that would allow you to change the bootloader to something better suited for your needs (eg. Check updatefile in ext. Flash for signature/checksum and update on match).

Sadly, it's not documented...
Maybe they really "forgot" to enable this...  We'll never know...

73

[iMo]

When I can put 32kB of "flash" on the mcu chip, I can easily place another XXXkB of flash there as well. As I wrote in my previous post, I can remember on discussions in past (with the introduction of the CH32F103 and friends) the dual chip is because they have some issues with integrating their "flash technology" with the technology they use with their MCUs. It was some 10y back, perhaps they mastered that already, but I still doubt they do. The dual chip config is a big complication for their production, imho.

[brucehoult]

Afaik the first CH32F103 was dual chip with mcu chip and the spi flash chip on top, there are great die shots discussed here in past.

I think you're thinking of Gigadevice and the GD32VF103 and also Arm version.

Moreover the company started as their major SPI flash chips manufacturer there, thus mcus was/is their secondary biz, afaik..

That's Gigadevice.

WCH is/was a big supplier of 8051 clones. I don't think they've ever made flash memory.

Totally unrelated companies AFAIK.

[HwAoRrDk]

I'm not really sure about the bootloader being hard coded.

I think one indication that it is hard-coded (or, at least, read-only) is the lack of a FLASH_BOOT_MODEKEYR register on the CH32V30x. On other CH32V models, like for example the CH32V003, that register is used to unlock writing to the bootloader flash area. If you can't unlock it for writing, that would imply you can't write to it...

[wilhe_jo]

I'm not really sure about the bootloader being hard coded.

I think one indication that it is hard-coded (or, at least, read-only) is the lack of a FLASH_BOOT_MODEKEYR register on the CH32V30x. On other CH32V models, like for example the CH32V003, that register is used to unlock writing to the bootloader flash area. If you can't unlock it for writing, that would imply you can't write to it...

Well, non-documented does not mean non-existing, but may imply non-functional...

- The bootloader is stored in "system Flash", it's an area separated from the Flash described above. It's not part of it. It's 28KB and its address is 0x1FFF_8000. Whether it can be user written, testing will tell.

Back when I first discovered this IC and read the available docs, i came to the conculsion, that 480k+28k+some area for Option-bytes,... would fit 512k flash...
Whether or not, the address decoder etc. support manipulating it... we may never really find out.

As you pointed out, the register definitions and de ref-manual do not explain how you could do it, the chinglish text, however, suggests it could have been at least been on the feature list during development of this IC.

BTW: Support says it can't be done. That's why it's not on my priority list ATM... getting the products done is more important

73

[iMo]

Afaik the first CH32F103 was dual chip with mcu chip and the spi flash chip on top, there are great die shots discussed here in past.

I think you're thinking of Gigadevice and the GD32VF103 and also Arm version.

Yep, you are right..
Anyhow, simply send a chip to Noopy and we get more on the setup..

[bingo600]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

I think its not persistent.

One more thing you could try is minichlink https://github.com/cnlohr/ch32v003fun/tree/master/minichlink, not sure how it handles this button less module.

I found a Win10 PC , and used : WCH-LinkUtility to switch mode on my "Buttonless" WCHLINK to RiscV mode
It seemed to reflash the WCHLINK (V2.10) , and is now in RiscV mode. Also after a disconnect/Connect.

I have succesfully programmed the 307 board , with both the WCHLINK , and the WCHLINK-E
According to Doc , you need the WCHLINK-E to program the small 20-pin ssop, but both can program a 307


Edit:
While at it ... You might want to do a "Conect to WCHLINK" , in the utility , for all your programmers.
My WCHLINK-E. was updated to a later firmware (2.11) 

/Bingo

[bingo600]

There's a bit of definitions in the : WCHISPTool_CMD.ZIP     - Commandline programmer

Some source and API headers , but the "Goodies" is in a library w. no src

Maybe someone can deduct some info from the API include files
I'm especially thinking how2 set flash/mem partitioning on linux.

Seems like the "Config file" needed can be made/saved in the

The configuration file is generated by the "Save UI Config" function of WchIspStudio.exe

/Bingo

[jnk0le]

I found a Win10 PC , and used : WCH-LinkUtility to switch mode on my "Buttonless" WCHLINK to RiscV mode
It seemed to reflash the WCHLINK (V2.10) , and is now in RiscV mode. Also after a disconnect/Connect.

Does it remain when moved to linux pc, or just the driver?

[bingo600]

I found a Win10 PC , and used : WCH-LinkUtility to switch mode on my "Buttonless" WCHLINK to RiscV mode
It seemed to reflash the WCHLINK (V2.10) , and is now in RiscV mode. Also after a disconnect/Connect.

Does it remain when moved to linux pc, or just the driver?

It reprograms the programmer.
And it remains RiscV - When moved/connected to linux


Edit:
My wchlink programmer also registers as an usb uart ttyACM0
Helps a lot with an uart for messages.

Might be why there was a ch3xx Win driver included.

Linux doesn't need a driver.

[bingo600]

ddrown wrote something interesting about the flash/ram partitioning here

https://github.com/cnlohr/ch32v003fun/issues/232#issuecomment-1694923415

Edit ....

Based on that  (3f,ff,bf,7f)

Code: [Select]

128k.txt:81:06:08:02:3f:ff:ff:ff:ff:ff:ff
32k.txt:81:06:08:02:ff:ff:ff:ff:ff:ff:ff
64k.txt:81:06:08:02:bf:ff:ff:ff:ff:ff:ff
96k.txt:81:06:08:02:7f:ff:ff:ff:ff:ff:ff

It could be that this command (two upper bits) controls a 64K (bit 7 = 0) and 32K (bit 6 = 0) Ram bank

If the MCU always has 32K Ram , then you can switch in an extra 64K and/or 32K by setting the cooresponding bit to ZERO

I have no idea (yet) if these are MCU register bits or Programmer "instructions

[SiliconWizard]

I am able to read the bootloader. The first instruction is jal x0, 5842. Haven't disassembled it fully yet.
Haven't tried writing to this area yet. For all I know, it may be possible to write to it just like any other area of the Flash on the CH32V30x. Something I'll try later on.

I am going however to try defining a section in the Flash in the non-zero-wait area, place some data in it, and see how it goes. I'll also try running code from there after that, although I'm less positive it'll work. We'll see.

The only doubt I have is the total amount available depending on the version of the chip. The CH32V305 for instance has less available RAM and Flash (according to the DS), but it's unclear if it's just an artificial limitation and the chip may still have the full 320KB RAM and 480KB Flash as well.

[SiliconWizard]

* NOTE for everyone using the SDK linker script or a modified version thereof. *

They have defined the .bss section with the following memory placement:

Code: [Select]

>RAM AT>FLASH , as for the .data section.
I think this is pretty wrong. It should be only

Code: [Select]

>RAM as far as I know. Otherwise, it will eat space in Flash for the unitialized data. It's possible that it'll be optimized out by the linker eventually, although I'm not completely sure.

For people skilled at writing linker scripts, let me know your thoughts.

[wilhe_jo]

There are other quirks in there as well... LTO doesn't work because interrupts get "optimized" out.

At the first glance, everything should do, but I'm sure I missed some attribute for the prototypes/vector tables.

Up to now I se just 30k, so not enough motivation ATM to investigate this issue further.

The Mounriver studio is missing C++ as well...

All in all, it's fine to get some first prototype ready, but needs some polishing... Similar to all other Dev environments I used so far.... None is perfect.

But the peripheral libs all seem sound so far...way better than eg. STM hal or non-standard stuff in esp-idf.

73

[SiliconWizard]

There are other quirks in there as well... LTO doesn't work because interrupts get "optimized" out.

It's not really specific to this I think. I've seen that with ARM MCUs as well The usual treatment is to add the "used" attribute to prevent the linker from pruning code/variables that it thinks are not referenced. Try that and let us know. I usually don't use LTO on embedded stuff, so I haven't encountered that, but this attribute should help.

[wilhe_jo]

I've seen that with ARM MCUs as well

That's what I meant with "none are perfect"

My guess is, that there's also some problem with the weak definitions.
If "used" is missing, there should be a unknown reference as well and/or the vector should be missing.
Need to dig into the lst and map files at some point ...

73

[HwAoRrDk]

They have defined the .bss section with the following memory placement:

Code: [Select]

>RAM AT>FLASH , as for the .data section.
I think this is pretty wrong. It should be only

Code: [Select]

>RAM as far as I know. Otherwise, it will eat space in Flash for the unitialized data. It's possible that it'll be optimized out by the linker eventually, although I'm not completely sure.

I've been trying to learn about linker scripts, and I noticed this same thing in the CH32V003 linker script supplied by WCH when I was trying to understand it. I did think it was odd that the BSS section would have a load address (LMA) specified, when there is nothing to load for BSS (because of course it's the startup code that zeroes out this section in RAM). So I'm not sure it matters, because there will be no actual content for that section.

With that said though, checking the map file output by the linker for a CH32V003 project of mine using this linker script, it says that my .bss section is 228 bytes in size and has a load address of 0x3310; that address does actually exist in my output firmware image, but it is a single 0x00 byte at the very end. So I guess technically it is "eating" space in flash. I wonder where this single byte comes from, or if it is perhaps just an artefact of "if the section exists, there has to be something in it".

[SiliconWizard]

Probably. It's best to fix the linker script and make it clean.

Using the NZW Flash area with a dedicated section is doable - the small hiccup right now is that this area of Flash is *not* mapped right after the normal code area (which is remapped at address 0), so it must be accessed from its base address, which is an offset of 0x0800_0000. No problem, you just need to define the origin appropriately, like this for instance:

Code: [Select]

FLASH_NZW (rx) : ORIGIN = 0x08000000 + LENGTH(FLASH), LENGTH = 480K - LENGTH(FLASH)
Then add a section like this:

Code: [Select]

.flash_nzw_data :
{
. = ALIGN(4);
*(.flash_nzw_data)
. = ALIGN(4);
} >FLASH_NZW
And there you go. Almost.

Now, since the code area and this NZW area will be far apart from the perspective of the linker, that will generate a huge .bin file, if you use binary files. With this, you can't. It would be much too large (> 128MB with most of it zero.)
So you'll have to stick to elf or hex. Which is still all fine for the most part. But now you need a programming tool that can Flash different non-consecutive blocks in a smart way rather than as a contiguous block, and there is not much that can do this at the moment. A small issue, but no real tool for flashing, unless you write your own. The wlink tool (written in Rust) that I'm using can't do that, but there is a ticket for this as a feature request. We'll see. Maybe openocd can do this, I'm not sure, haven't tried it yet.

Otherwise, we would have to stick to other approaches, a bit less convenient - the problem is kinda similar to the typical bootloader + user app in a single object file thing.

[tellurium]

They have defined the .bss section with the following memory placement:

Code: [Select]

>RAM AT>FLASH , as for the .data section.
I think this is pretty wrong. It should be only

Code: [Select]

>RAM as far as I know. Otherwise, it will eat space in Flash for the unitialized data. It's possible that it'll be optimized out by the linker eventually, although I'm not completely sure.

For people skilled at writing linker scripts, let me know your thoughts.

Correct. BSS should not occupy any space in the compiled binary, and should not take any space on flash.

[wilhe_jo]

Using the NZW Flash area with a dedicated section is doable - the small hiccup right now is that this area of Flash is *not* mapped right after the normal code area (which is remapped at address 0), so it must be accessed from its base address, which is an offset of 0x0800_0000. No problem, you just need to define the origin appropriately, like this for instance:

IIRC, you can tell the linkerfile where code lives in the binary and where it would execute (I seldomly have the need to dig that deep).

Hence, it should be possible, to have all the flash starting at 0x08... in the binary (1 block) and have 2 sections executing in different places.
But you could just move everything into the 0x08... range.

I mean what could go wrong?
The cpu resets, maps 0x08.. to 0x00.. (I read the manual, that this memory lives in 2 locations as for eg. the Cortex M) and loads an address in the 0x08... region.
That should be executeable as well and therefore it should "just" work, right?

Worst case would be to use -fPIC...

This would be a massively interesting thing... use the full 480k flash and 128k ram.

73

[bingo600]

I have just "enhanced" minichlink (for the wchlink(-e) dongle) with ram partitioning  - On programming.
Thanx to ddrown for doing the hard work.

See attachments


I have only tested 64K Ram for now.
That's what ddrown's lwip example uses in the linker.


/Bingo

[wilhe_jo]

<edit>
ok.. I played around... it may really, really work...

I added a mapped section:

Code: [Select]

MAPPED(rx) : ORIGIN = 0x00000000, LENGTH = 288K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 480K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
Then I switched ">FLASH AT>FLASH" to ">MAPPED AT>FLASH"

next, I switched the openocd stuff

Code: [Select]

#interface wlink
adapter driver wlinke
adapter speed 3000
transport select sdi

wlink_set_address 0x08000000
set _CHIPNAME wch_riscv
sdi newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x00001

set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME.0 wch_riscv -chain-position $_TARGETNAME
$_TARGETNAME.0 configure  -work-area-phys 0x20000000 -work-area-size 10000 -work-area-backup 1
set _FLASHNAME $_CHIPNAME.flash

flash bank $_FLASHNAME wch_riscv 0x08000000 0 0 0 $_TARGETNAME.0

echo "Ready for Remote Connections"

Now programming works as if everything was at 0x00, it runs (at least for me) and you should be able to put section not into the mapped region (ie. into the first 192...288k flash).
If you execute from the 0x08 region, wired stuff happend... I dunno if this is because you shoudn't, or I was just stupid...


73

[bingo600]

ddrown talks about interrupts here, and how to get "stock" riscv-gcc to do "fast interrupt"
https://blog.dan.drown.org/ch32v307-dev-board-part-2/


/Bingo

[brucehoult]

ddrown talks about interrupts here, and how to get "stock" riscv-gcc to do "fast interrupt"
https://blog.dan.drown.org/ch32v307-dev-board-part-2/

This issue has been extensively discussed here in the past.

If you are going to call such a heavyweight thing as printf() then there is no point worrying about a few cycles more or less in the interrupt handler prologue and epilogue -- just use a standard RISC-V interrupt attribute (option 1) and don't enable WCH's "fast interrupt" (HPE) feature (or it doesn't matter if you do, just a little more wasted work).

Option 1 is also a good option is you delete the printf() as the code will only use 3 registers, which take very little time to save and restore. Not as fast as using HPE, but close, and a couple of cycles quicker than Option 2.

Option 1 is the ONLY CORRECT choice if your handler -- or anything it calls -- uses floating point. Do you *know* that printf() won't use FP at all? It probably won't but if it does then the interrupted code will be very very unhappy.

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.


Option 2 is functionally equivalent to using WCH's patched compiler, and is slower only by two instructions jal, and ret.

User @jnk0le has an official proposal in for a "prestacked" attribute to be implemented in __attribute__((interrupt)) in gcc and llvm which will allow you to use Option 1 without redundantly saving and restoring a0-a7,t0-t6,ra. 

[wilhe_jo]

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.

Hmmm this must be the reason for using softfp as the default...

Regards

[martinribelotta]

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.

While this is mostly true, it is not entirely correct:

The GCC provided by MounRiver push correctly the FPU registers in the stack via software when you indicate -march=rv32imafc -mabi=ilp32f but this behaviour break the advantage of fast interrupt when hardware-stacked registers.

In fact, you can use hardware-stacked registers and FPU interrupt but don't expect much improvement between "WCH-FastInterrupt" and standard "interrupt"

[wilhe_jo]

Seems similar to cortex-m....

I really need to dig into risc-v ...
But 10y of cortex-m vs first 2 projects in parallel with CH32...
There're some things to learn about this new architecture

All in all the ASM looks already semi intuitive.

But I'm not sure about some "instabilities" during debugging.
Time to time a power cycle seems needed in order to fix debugging problems (single stepping stops working).
I'm not sure if it's EMI, user stubitity, soft- or hardware problems.

Anyhow. I'm positively surprised so far.

Moving this stuff to upstream GCC (what about llvm on risc-v? I tend to like the llvm warnings/errors better) comes next...
One of the projects will go open-source (6ghz power sensor).
That'll definitely move...
But first I need to get the last bits semi tidy.
For now, the hardware is verified and most of the firmware architecture has fallen into place (TinyUSB works pretty easily and performs adequately well... but has it's own quirks).

73

[brucehoult]

Seems similar to cortex-m....

Technically, the RV32IMAFC instruction set used by the CH32V307 is very similar to Cortex-M4F. Both use a mix of 2-byte and 4-byte instructions for great code density and have single precision FP.

Being not actually the same ISA they made some different decisions and each has some small advantage over the other in some specific area e.g. Arm has more addressing modes which can save a couple of instructions on array accesses, while RISC-V has single instruction compare-and-branch which is used more often in most code. RISC-V has 32 integer and 32 FP registers compared to ARMv7-M's 16 integer registers and 32 FP registers. RISC-V has more registers that need saving on an interrupt, but in the absence of interrupts often runs faster because more variables can be kept in registers not on the stack. Also, WCH's HPE option (which is not standard RISC-V) allows the CH32V307 to save all needed registers instantly to a set of shadow registers.  Note: RISC-V has a RV32E variant with only 16 integer registers, and this is used in the low end CH32V003.

Moving this stuff to upstream GCC (what about llvm on risc-v? I tend to like the llvm warnings/errors better) comes next...

LLVM has supported RISC-V for quite some time. I published the first ready-to-build LLVM supporting RISC-V just over four years ago:

https://github.com/sifive/riscv-llvm

Many many improvements and new features have been added in the last four years and LLVM is now the preferred compiler for RISC-V for many projects. It definitely gets support for new ISA extensions faster (not that this is relevant to microcontrollers using only very core instructions)

[bingo600]

openvch just updated EVT sdk,boards & schematics
https://github.com/openwch/ch32v307

[mikeselectricstuff]

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.

While this is mostly true, it is not entirely correct:

The GCC provided by MounRiver push correctly the FPU registers in the stack via software when you indicate -march=rv32imafc -mabi=ilp32f but this behaviour break the advantage of fast interrupt when hardware-stacked registers.

In fact, you can use hardware-stacked registers and FPU interrupt but don't expect much improvement between "WCH-FastInterrupt" and standard "interrupt"

If you're using FP in an interrupt handler you're probably doing things wrong.

[wilhe_jo]

Well, if you have a FPU the floating point operations aren't that expensive.
I don't see too many reasons why you shouldn't do floats in interrupts at all.

I mean, the difference is pushing some more registers...
It all depends on the architecture and the algorithms you need to implement.

But you're right.
A bazooka would be a bad tool to get a hole for a screw anchor into a wall.
OTOH, if you're tasked to quickly convert a house into dust, it may actually work in some regions of this world...

Btw, anyone knows if wch has some information on clocks per instruction?
The QingKeV4 manual misses these details...

73

[SiliconWizard]

Well, not saving the FP registers in the hardware stacks is not an unreasonable decision. That's half of the space for a reasonable compromise. While FP instructions could be used in ISRs in some cases, not using them is not a huge deal.
And again, as Bruce said, if you absolutely want to use them, don't rely on the hardware stacks, just use the regular 'interrupt' attribute. Solved.

[brucehoult]

And again, as Bruce said, if you absolutely want to use them, don't rely on the hardware stacks, just use the regular 'interrupt' attribute. Solved.

If you're using upstream gcc, yes.

If you're using WCH's patched gcc then it depends on whether they implemented __attribute__((WCH-Interrupt-fast)) as "normal function that uses mret instead of ret (and possibly also doesn't save ra if another function is called) or as "__attribute__((interrupt)) that doesn't save ra,a0-a7,t0-t6".

A comment by martinribelotta appears to indicate it is the latter.

[SiliconWizard]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

[brucehoult]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

[SiliconWizard]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

I would have thought that keeping the original behavior of the 'interrupt' attribute itself, and only changing it for the new, vendor attribute 'WCH-Interrupt-fast' - would have made sense. Breaking existing behavior is bad.
Without it having to mean a particularly complicated patch. So that one could still use either and have either behavior. But what have they done, who knows. Where is the patch (if you or someone else has a link?)

[brucehoult]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

I would have thought that keeping the original behavior of the 'interrupt' attribute itself, and only changing it for the new, vendor attribute 'WCH-Interrupt-fast' - would have made sense. Breaking existing behavior is bad.
Without it having to mean a particularly complicated patch. So that one could still use either and have either behavior. But what have they done, who knows. Where is the patch (if you or someone else has a link?)

FFS. It DOES NOT break existing behaviour. With the patch you have normal functions, __attribute__((interrupt)) functions, and __attribute__((WCH-Interrupt-fast)) functions.

The QUESTION is: which of the first two is the latter a modification of?

Clear enough?

[SiliconWizard]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

I would have thought that keeping the original behavior of the 'interrupt' attribute itself, and only changing it for the new, vendor attribute 'WCH-Interrupt-fast' - would have made sense. Breaking existing behavior is bad.
Without it having to mean a particularly complicated patch. So that one could still use either and have either behavior. But what have they done, who knows. Where is the patch (if you or someone else has a link?)

FFS. It DOES NOT break existing behaviour. With the patch you have normal functions, __attribute__((interrupt)) functions, and __attribute__((WCH-Interrupt-fast)) functions.

The QUESTION is: which of the first two is the latter a modification of?

Clear enough?

Not really. I'm sure it comes from a misunderstanding of what exactly each other means, adding to that the fact that you have worked on GCC, so some things may look obvious to you when they aren't necessarily to others.

What I was meaning by "existing behavior" is the behavior of mainline GCC when using the interrupt attribute with a RISC-V rv32imafc target. I'm assuming that it has a common behavior in all cases, unless you specify another attribute than the bare "interrupt" one. Maybe that's not exactly how things are implemented for RISC-V targets, so let me know if this isn't the case.

Going from there, my assumption was that if WCH's patched version behaves identically to mainline GCC when using the bare "interrupt" attribute, then it should not make any difference whether you use mainline GCC or their patched version, if using this attribute. That sounds logical to me. Maybe it isn't to GCC. Or maybe we weren't talking about the same thing.

You last question "which of the first two is the latter a modification of?" leaves me puzzled instead of being clear to me, but that's possibly because you have hands-on experience developing back-ends for GCC when I don't.
As a user - not a GCC developer - I would logically think that WCH would have piggybacked on the existing RISC-V back-end, leaving the "interrupt" behavior as is, and switching to their own behavior when specifying the "WCH-Interrupt-fast" attribute instead. So I don't understand the question. But that may again be because something extremely obvious to you in the way GCC back-ends are structured in general, and the status with the RISC-V one in particular, is not to me.

So without a detailed knowledge of GCC internals, my naive view is that if the "interrupt" attribute on their patched version doesn't exactly behave as the "interrupt" attribute on mainline GCC, then that's what I was calling "breaking existing behavior". The only thing that may be the missing piece here - again probably 100% obvious to you and not to me - is that the bare "interrupt" behavior may be dependent on the extra extensions WCH has defined (when using -march=rv32imacxw), while I'm sticking to "rv32imafc". If so, that would look a bit messy to me. If not, then I still don't get it, and so I'm probably dense. (Btw, I suppose their extension is "w", but what is "x"? or maybe it's "xw"? Oh and they don't seem to enable FP support in their example makefiles. Go figure.)

And with all that said, it looks like WCH still hasn't released the source code for their patch, unless I've missed it. At least that's what appears to be the case on their openwch github, with an unanswered ticket from some user. Which doesn't bode too well to me. But I'll stick to mainline GCC anyway. At least until they relase their patch. And if they have, I'll be glad to have a look. Popcorn time.

[brucehoult]

Not really. I'm sure it comes from a misunderstanding of what exactly each other means, adding to that the fact that you have worked on GCC, so some things may look obvious to you when they aren't necessarily to others.

Nothing to do with gcc specifically, just standard software development practices.

What I was meaning by "existing behavior" is the behavior of mainline GCC when using the interrupt attribute with a RISC-V rv32imafc target. I'm assuming that it has a common behavior in all cases, unless you specify another attribute than the bare "interrupt" one.

Yes, of course.

Going from there, my assumption was that if WCH's patched version behaves identically to mainline GCC when using the bare "interrupt" attribute, then it should not make any difference whether you use mainline GCC or their patched version, if using this attribute.

Yes, of course.

You last question "which of the first two is the latter a modification of?" leaves me puzzled instead of being clear to me, but that's possibly because you have hands-on experience developing back-ends for GCC when I don't.

Nothing to do with gcc, just standard software development practices.

As a user - not a GCC developer - I would logically think that WCH would have piggybacked on the existing RISC-V back-end, leaving the "interrupt" behavior as is, and switching to their own behavior when specifying the "WCH-Interrupt-fast" attribute instead.

Yes, of course.

Except it's not a choice between "interrupt" and "WCH-Interrupt-fast", it's a choice between both of those and normal non-interrupt C functions.

So I don't understand the question.

The question is: is "WCH-Interrupt-fast" more similar to standard C functions (just replace `ret` with `mret`), or is it more similar to "Interrupt"?

But that may again be because something extremely obvious to you in the way GCC back-ends are structured in general, and the status with the RISC-V one in particular, is not to me.

Nothing to to with gcc, just standard software development practices.

You don't write code from scratch if you can avoid it. You copy-and-paste existing code (bad), or add some if/then/else to existing code (good).

So without a detailed knowledge of GCC internals

No knowledge of gcc required, just standard software development practices.

if the "interrupt" attribute on their patched version doesn't exactly behave as the "interrupt" attribute on mainline GCC, then that's what I was calling "breaking existing behavior".

Of course. And of course it does not break existing behaviour, as I've said repeatedly. Why would it? That would be stupid.

The only thing that may be the missing piece here - again probably 100% obvious to you and not to me - is that the bare "interrupt" behavior may be dependent on the extra extensions WCH has defined (when using -march=rv32imacxw), while I'm sticking to "rv32imafc".

No. The I'm sure the only relevant WCH extension is the CSR bit that tells it to save ra,a0-a7,t0-t6 (or the implemented subset of those on the '003) before calling the interriupt handler in the standard way.

And with all that said, it looks like WCH still hasn't released the source code for their patch

I don't know. I haven't looked for it, and don't use their compiler.

That's why I'm speculating about which existing functionality (standard C function, or "interrupt" function) "WCH-Interrupt-fast" handling is more similar to, rather than stating the behaviour as fact.

[ali_asadzadeh]

Guys has any one done any example project with FreeRTOS, Ethernet and USB Device CDC combined? I'm trying to combine these, and I get lot's of crashes and headaches

[ali_asadzadeh]

Here the FreeRTOS and Ethernet port try, it would not do anything on Ethernet, see the modified  project, it would not even ping!

I have combined the FreeRTOS and Ethernet webserver examples, in order to do that I had to modify the
Delay_Ms and Delay_Us functions in debug.c file like this

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}


void Delay_Ms(uint32_t n){
  vTaskDelay(n);
}

[jnk0le]

Code: [Select]

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}
This is not going to work. Will be optimized away at any optimization level.

[brucehoult]

Code: [Select]

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}
This is not going to work. Will be optimized away at any optimization level.

Adding asm volatile ("") as the body of the loop will prevent that.

But it's still a VERY VERY bad idea because the correct value of p_us will depend on the exact CPU, the optimisation level, the compiler being used, and the phase of the moon.

e.g. with current RISC-V gcc with -O{1,2,3} the body of the loop is:

Code: [Select]

.L3:
        addi    a5,a5,1
        bne     a5,a0,.L3
        ret

... but with -Os ...

Code: [Select]

.L2:
        bne     a0,a5,.L3
        ret
.L3:
        addi    a5,a5,1
        j       .L2

... which will have very different timing, possibly something like 5 cycles vs 3 per loop (3 stage pipeline, no branch prediction)

At the very least, write it in assembly language so you know what instructions are being run and with what scheduling. That avoids all but the first problem above.

[Sueco]

Hi all,

I've been playing around with the CH32V307VCT6 flash memory, so far I've been unable to execute code from the flash proper, but that might require some deep digging, should be doable since the BLE examples provided for the similar CH32V208 seem to use the full memory range. What I've able to do is take advantage of the extra flash beyond the  288KB max boundary by tweaking slightly the linker script, I added a new memory region:

Code: [Select]

FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 288K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
ROM (r) : ORIGIN = 0x00048000, LENGTH = 192K
Of course this could be easily altered to any of the available combinations 256K+64K, leaving 224K for ROM, etc

I removed .rodata from .text:

Code: [Select]

.text :
{
. = ALIGN(4);
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
. = ALIGN(4);
} >FLASH AT>FLASH
And defined a new section .constants:

Code: [Select]

.constants :
{
. = ALIGN(4);
*(.rodata)
*(.rodata*)
. = ALIGN(4);
} >ROM
   
This results in all constants declared in all the code (including implicit constant strings used in printf) to be stored in NZW flash, freeing some space for code. This might be quite useful if a lot of constant non executable data is required for a particular application such as http server, LUTs, etc... It's so effective that I think it should be included by default in the example linker scripts. Unless this might result in something unexpected that I failed to foresee?

Just one oddity, there was some speculation about the absurdity of .data and .bss being allocated as >RAM AT>FLASH. Well I switched .data to >RAM and the program crashes, why I'm not sure as yet.

Of course if executing from FLASH at 0x800 0000 is possible I'd very much like to get the full 480K plus 320K of RAM, I'd probably accept slower execution in exchange for the extra resources, I'm thinking of something in the line of placing a jump to somewhere at 0x0800 0000+ right in the reset vector, but so far I've only got hard faults doing that.

[mikeselectricstuff]

Code: [Select]

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}
This is not going to work. Will be optimized away at any optimization level.

for(i=0;i<p_us*n;i++) asm("nop");
will work

[HwAoRrDk]

Well I switched .data to >RAM and the program crashes, why I'm not sure as yet.

I'm not surprised. By removing "AT>FLASH" you just told it that the contents of .data don't need to be loaded and initialised from flash at startup. That is, all your global/static variables with default values won't have them anymore.

[brucehoult]

Well I switched .data to >RAM and the program crashes, why I'm not sure as yet.

I'm not surprised. By removing "AT>FLASH" you just told it that the contents of .data don't need to be loaded and initialised from flash at startup. That is, all your global/static variables with default values won't have them anymore.

That might work immediately after you download the app as openocd will literally write the default values into RAM. They'll be gone if you power off, of course, or maybe even if you reset, and even if reset doesn't nuke them, on a 2nd run they'll not be set back to initial values but whatever they ended up as.

[bingo600]

I just had a headscratcher with some new ch32v307 boards

I got a few of these boards - And they came with flash protection enabled from the factory.
https://www.aliexpress.com/item/1005004350410929.html

Since i was lazy and wanted to use DFU Programming , i had to do some trickery to solve that.

See here
https://www.eevblog.com/forum/microcontrollers/ch32v307-modbus-web-ui-firmware/msg5312677/#msg5312677

/Bingo

[LM2023]

I have no idea (yet) if these are MCU register bits or Programmer "instructions

Here you can find an excellent description of V20x and V30x versions that have "reconfigurable" ram/flash mapping:
https://github.com/cnlohr/ch32v003fun/issues/280
You just need to write to Option Byte Register (FLASH_OBR) to select how much flash is copied and remapped into sram at next reboot (its value is preserved in user option bytes flash region).

FLASH_OBR and other configuration registers are initialized at reset by reading the option byte flash region
(see "32.6 User Option Bytes" in CH32FV2x_V3xRM.PDF reference manual covering CH32F2xx, CH32V2xx and CH32V3xx).

Option Bytes can be rewritten at runtime (You need to "unlock" them by writing to specific registers, etc. see descriptions in 32.6.xx  ) and have a different format compared to the registers they remap to, usually you just use the WCH utility to
configure the option bytes and just compile and link your code based on the expected configuration, but it is also possible to implement a "self-configuring" firmware by having a bootloader that checks if FLASH_OBR has the expected mapping and if not, rewrites the Option Bytes and reset the chip so at next boot the mapping will be correct.
(i.e. you code the bootloader configured for the "worst case" configuration of only 32KB of R/W SRAM and map it in the first 192KB of R0WAIT flash, after is successfully pass the SRAM/R0WAIT flash configuration check, before initializing the actual application firmware it remaps stack, etc. to the actual application's memory mapping).

For CH32V307 (RC, WC or VC) you have 320KB sram and 480KB flash and the bits in FLASH_OBR select how much flash gets copied into sram that gets remapped as R0WAIT flash.

FLASH_OBR bit9,bit8	"accessible" SRAM size	"remapped" R0WAIT_FLASH size	"slow" flash size [N.B. starts at 0x0800 0000 + (R0WAIT_FLASH size)]
00	128KB	192KB	288KB
01	96KB	224KB	256KB
10	64KB	256KB	224KB
11	32KB	288KB	192KB

Edit: Got the register <--> option bytes dependency wrong, corrected it and added more details.

[John Celo]

Does this chip stack well against STM32H750 price/feature wise?

STM32H750 has ethernet MAC and roughly 3 eur a piece for 10 units.
ch32v307 are only slightly cheaper at low volumes (2.75eur a piece for 10)?

Or does ch32v307 have more fully featured ethernet implementation? Or something else?

[ataradov]

STM32H750 has ethernet MAC and roughly 3 eur a piece for 10 units.

Where are you getting it at that price? It normally goes for about $10 @ 10 pcs.

Ok, I see LQFP-100 version on LCSC for $3.3 @ 10 pcs.

If you can reliably get STM32 at this price, I'd go with STM32.  But I'm not sure how reliable is LCSC supply. And you are not getting it for $3 from Mouser or any other common distributor.