ch32v307, risc-v minicore with ethernet - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: April 26, 2022, 09:56:25 am
content: Suggested here yesterday by a forum member, thech32v307looks very interesting (at least on the paper)Seehererisc-v@144Mhz64K RAM256K flashEthernetUSB2.0i2cspiuart (8 channels!!!)adcrtc...very nice!anyone going to use one?

author: hans
author_rank: Super Contributor
timestamp: April 26, 2022, 12:45:06 pm
content: 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 HSintegratedphy, 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-markA Cortex-m3/m4 can reach 3.5 Coremark/MHz with a modern compiler.It's actually more on par with a Cortex-m0.

author: mon2
author_rank: Frequent Contributor
timestamp: April 26, 2022, 02:39:51 pm
content: QuoteYes, 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.htmlUpdate - sharing a very responsible contact at the WCH factory:Quote

author: newbrain
author_rank: Super Contributor
timestamp: April 28, 2022, 06:25:09 am
content: 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?).

author: westfw
author_rank: Super Contributor
timestamp: April 28, 2022, 07:59:00 am
content: QuoteSeems a bit tiny to run 8uarts worth of any modern networking stack.Maybe it could run LAT.

author: ve7xen
author_rank: Super Contributor
timestamp: April 28, 2022, 08:16:37 am
content: Quote from: hans on April 26, 2022, 12:45:06 pmIn 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.QuoteDefinitely 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.

author: tszaboo
author_rank: Super Contributor
timestamp: April 28, 2022, 08:47:51 am
content: Quote from: hans on April 26, 2022, 12:45:06 pmYou 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?

author: DiTBho
author_rank: Super Contributor
timestamp: April 28, 2022, 09:16:32 am
content: Quote from: westfw on April 28, 2022, 07:59:00 amProbably 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.

author: woofy
author_rank: Frequent Contributor
timestamp: April 28, 2022, 09:45:52 am
content: Quote from: tszaboo on April 28, 2022, 08:47:51 amNot that I can see, it does not have QSPI. It does have SD card interface though.Quote from: DiTBho on April 28, 2022, 09:16:32 amThere 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.

author: martinribelotta
author_rank: Regular Contributor
timestamp: April 28, 2022, 01:03:58 pm
content: 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 algorithmBoth 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/PIC24Anyone 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...

author: newbrain
author_rank: Super Contributor
timestamp: April 28, 2022, 01:46:25 pm
content: Quote from: woofy on April 28, 2022, 09:45:52 amQuote from: ve7xen on April 28, 2022, 08:16:37 amQuote from: newbrain on April 28, 2022, 06:25:09 amAnd we all chose theright dayto do that

author: DiTBho
author_rank: Super Contributor
timestamp: April 28, 2022, 02:58:35 pm
content: Quote from: martinribelotta on April 28, 2022, 01:03:58 pmYes, 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...

author: ve7xen
author_rank: Super Contributor
timestamp: April 28, 2022, 06:41:32 pm
content: Quote from: martinribelotta on April 28, 2022, 01:03:58 pmTotally 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 herehttps://github.com/MarsTechHAN/ch552tool/pull/22and herehttps://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...

author: westfw
author_rank: Super Contributor
timestamp: April 29, 2022, 01:37:29 am
content: QuoteHmm. 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...)

author: newbrain
author_rank: Super Contributor
timestamp: April 29, 2022, 07:42:10 am
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: April 29, 2022, 09:23:01 am
content: Quote from: westfw on April 29, 2022, 01:37:29 amYup, but so also says the manual of my DEC-terminal. 80msec is the max value you can set

author: DiTBho
author_rank: Super Contributor
timestamp: April 29, 2022, 09:37:09 am
content: Quote from: westfw on April 29, 2022, 01:37:29 amyup, 512Kbyte on 68k; 1Mbyte on Tektronix MIPS R3K for LAT + Vt100, 32Mbyte for x11+tcp/ip+twm+xterm+telnetIn 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 }

author: martinribelotta
author_rank: Regular Contributor
timestamp: April 29, 2022, 01:51:46 pm
content: 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-rvBut lacks flash write support

author: newbrain
author_rank: Super Contributor
timestamp: April 29, 2022, 02:31:35 pm
content: Quote from: martinribelotta on April 29, 2022, 01:51:46 pmYes, 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.cEveryone interested can find the whole shebang here:https://github.com/newbrain/riscv-openocd-wch.gitI did not try a compare against OpenOCD code.

author: newbrain
author_rank: Super Contributor
timestamp: April 29, 2022, 02:47:48 pm
content: BTW: a little note about GPL.GPL does not mandate that the source be accessible toeveryone, but only to theusersof 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".

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 29, 2022, 04:43:57 pm
content: 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.

author: ve7xen
author_rank: Super Contributor
timestamp: April 29, 2022, 05:14:05 pm
content: @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.

author: tszaboo
author_rank: Super Contributor
timestamp: April 29, 2022, 05:33:48 pm
content: Quote from: woofy on April 28, 2022, 09:45:52 amThat'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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 29, 2022, 06:07:04 pm
content: Quote from: ve7xen on April 29, 2022, 05:14:05 pmI 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.

author: westfw
author_rank: Super Contributor
timestamp: April 30, 2022, 02:48:26 am
content: QuoteReference? 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: April 30, 2022, 07:45:07 am
content: 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 ?

author: hans
author_rank: Super Contributor
timestamp: April 30, 2022, 12:14:12 pm
content: Quote from: tszaboo on April 28, 2022, 08:47:51 amGood 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.Quote from: SiliconWizard on April 29, 2022, 04:43:57 pmI think you first thought is a genuine truthI'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 ispossible, 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.

author: DiTBho
author_rank: Super Contributor
timestamp: April 30, 2022, 01:53:15 pm
content: Quote from: westfw on April 30, 2022, 02:48:26 amYou scanned some manuals, while I own a couple of brand new DEC-terminals with their weird keyboards and paper manualsI 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 thetermcapsupport 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 itBack 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

author: ve7xen
author_rank: Super Contributor
timestamp: May 14, 2022, 03:12:24 am
content: 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:Info : WCH-Link version 2.3Info : wlink_init okInfo : This adapter doesn't support configurable speedInfo : JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)Warn : Bypassing JTAG setup events due to errorsInfo : [riscv.cpu.0] datacount=2 progbufsize=8Info : Examined RISC-V core; found 1 hartsInfo : hart 0: XLEN=32, misa=0x40901125I did not have time today to try building a hello world.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 14, 2022, 03:21:40 am
content: Just downloaded the datasheet to get a better idea of the whole thing.

author: woofy
author_rank: Frequent Contributor
timestamp: May 14, 2022, 03:43:05 pm
content: 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?

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: May 14, 2022, 04:48:04 pm
content: Quote from: SiliconWizard on May 14, 2022, 03:21:40 amIs that the Chinese or the English data sheet - if you have a link to an EN one, I'd appreciate it

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 14, 2022, 05:04:29 pm
content: Quote from: SpacedCowboy on May 14, 2022, 04:48:04 pmEnglish. It's right on their website.http://www.wch-ic.com/downloads/CH32V20x_30xDS0_PDF.html

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: May 15, 2022, 02:03:12 am
content: Maybe there's something wrong with my internet, but whenever I try to click on that link (and I found the same thing viaGitHub) I get "site timed out"It looks as though the whole domain doesn't work for me... Never mind - got it via the wayback machine.

author: woofy
author_rank: Frequent Contributor
timestamp: May 15, 2022, 10:49:30 am
content: You will also need the reference manual.http://www.wch-ic.com/downloads/CH32FV2x_V3xRM_PDF.htmlUnable to attach here as its over the 4MB size limit.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: May 15, 2022, 03:04:01 pm
content: Quote from: woofy on May 15, 2022, 10:49:30 amYep, 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...

author: mon2
author_rank: Frequent Contributor
timestamp: May 15, 2022, 03:40:44 pm
content: Posting the latest reference manual from their website:https://mega.nz/file/akEA0arC#VpeSAWl88QnP0Zzst9SqxT63kE4jk4x3Il1uYjbi34c

author: newbrain
author_rank: Super Contributor
timestamp: May 16, 2022, 12:24:53 pm
content: 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 usingmretrather thanret, 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).

author: newbrain
author_rank: Super Contributor
timestamp: May 16, 2022, 12:28:11 pm
content: Quote from: ve7xen on May 14, 2022, 03:12:24 amMy fault, sorry - knowing OpenOCD can be built for Windows too I did not think of expanding the tar on a Lunix machine.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 16, 2022, 04:13:12 pm
content: Quote from: newbrain on May 16, 2022, 12:24:53 pmI 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.

author: ve7xen
author_rank: Super Contributor
timestamp: May 16, 2022, 05:34:48 pm
content: Quote from: evb149 on May 15, 2022, 01:53:40 amThe 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.QuoteThey 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.

author: woofy
author_rank: Frequent Contributor
timestamp: May 17, 2022, 10:29:03 am
content: 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 machineI've also tried with Win10 (in a VM) with the same results.

author: woofy
author_rank: Frequent Contributor
timestamp: May 19, 2022, 10:02:47 am
content: 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

author: newbrain
author_rank: Super Contributor
timestamp: May 19, 2022, 12:38:45 pm
content: Quote from: ve7xen on May 16, 2022, 05:34:48 pmNote that the default startup code write some flags toenable 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!

author: newbrain
author_rank: Super Contributor
timestamp: May 21, 2022, 04:18:48 pm
content: 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: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:Latency ns Latency cycles Delta cyclesHWS | 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 FreeHWS = Hardware StackingNo 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:#ifdef HWSvoid EXTI0_IRQHandler(void) __attribute__((interrupt("WCH-Interrupt-fast")));#elsevoid EXTI0_IRQHandler(void) __attribute__((interrupt("machine")));#endifQuote from: SiliconWizard on May 16, 2022, 04:13:12 pmYou 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.

author: newbrain
author_rank: Super Contributor
timestamp: May 21, 2022, 11:14:34 pm
content: Quote from: newbrain on May 21, 2022, 04:18:48 pmIn fact, using__attribute__((interrupt("WCH-Interrupt-fast")))is equivalent to__attribute__((naked)), plusasm volatile("mret")to return from the ISR.Thenakedavoids that all the registers are stacked at entry (and popped at exit), and themretwill provide the return to user mode from machine mode.At least, that worked with some simple test code...

author: woofy
author_rank: Frequent Contributor
timestamp: May 26, 2022, 08:48:50 am
content: Quote from: woofy on May 14, 2022, 03:43:05 pmI asked on github, it's coming!https://github.com/openwch/ch32v307/issues/20

author: martinribelotta
author_rank: Regular Contributor
timestamp: June 04, 2022, 10:21:39 pm
content: 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-gnumakeThis 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)

author: hydrabus
author_rank: Contributor
timestamp: December 21, 2022, 05:36:52 pm
content: For information I have released the toolchain to support RISC-V MCU with interrupt("WCH-Interrupt-fast")Seehttps://github.com/hydrausb3/riscv-none-elf-gcc-xpackPre-built version is also available herehttps://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1Any feedback are welcome as it has been tested only with HydraUSB3 v1 with WCH CH569 MCU so far

author: martinribelotta
author_rank: Regular Contributor
timestamp: December 22, 2022, 02:59:51 am
content: 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?

author: hydrabus
author_rank: Contributor
timestamp: December 24, 2022, 10:25:50 am
content: QuoteWhat do you mean by "add more multilib options?" ?Like explained inhttps://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1(it is a fork from originalhttps://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 --win64So it support all RISC-V with addition of special interrupt("WCH-Interrupt-fast") for WCH RISC-V and nothing has been removed

author: martinribelotta
author_rank: Regular Contributor
timestamp: December 24, 2022, 05:13:53 pm
content: Quote from: hydrabus on December 24, 2022, 10:25:50 amThe 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:crt0.o libgfortran.spec libnosys.a libsupc++.a rv32eac rv32i rv32iaf_zicsr rv32im rv32imc rv64ia rv64ic rv64ima rv64imc sim.specsldscripts libgloss.a libsemihost.a libsupc++_nano.a rv32ec rv32ia rv32ic rv32ima rv32imfc_zicsr rv64iac rv64ifc_zicsr rv64imac rv64imfc_zicsrlibc.a libgloss_nano.a libsim.a nano.specs rv32em rv32iac rv32ifc_zicsr rv32imafc_zicsr rv32imfdc_zicsr rv64iafc_zicsr rv64ifdc_zicsr rv64imafc_zicsr rv64imfdc_zicsrlibc_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_zicsrlibg.a libm.a libstdc++.a-gdb.py rv32e rv32emac rv32iafdc_zicsr rv32ifd_zicsr rv32imafd_zicsr rv32imf_zicsr rv64iafd_zicsr rv64if_zicsr rv64imafd_zicsr rv64imf_zicsrlibgfortran.a libm_nano.a libstdc++_nano.a rv32ea rv32emc rv32iafd_zicsr rv32if_zicsr rv32imaf_zicsr rv64i rv64iaf_zicsr rv64im rv64imaf_zicsr semihost.specsAnd your compilation have only this:Code: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.specsldscripts 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.specsYou can verify the bundled multilib libraries with-print-multi-libgcc option:Code:$> /opt/xpack-riscv-none-elf-gcc-12.2.0-1-wch/bin/riscv-none-elf-gcc -print-multi-lib.;rv32emac/ilp32e;@march=rv32emac@mabi=ilp32erv32ima/ilp32;@march=rv32ima@mabi=ilp32rv64imac/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=ilp32erv32ea/ilp32e;@march=rv32ea@mabi=ilp32erv32eac/ilp32e;@march=rv32eac@mabi=ilp32erv32ec/ilp32e;@march=rv32ec@mabi=ilp32erv32em/ilp32e;@march=rv32em@mabi=ilp32erv32ema/ilp32e;@march=rv32ema@mabi=ilp32erv32emac/ilp32e;@march=rv32emac@mabi=ilp32erv32emc/ilp32e;@march=rv32emc@mabi=ilp32erv32i/ilp32;@march=rv32i@mabi=ilp32rv32ia/ilp32;@march=rv32ia@mabi=ilp32rv32iac/ilp32;@march=rv32iac@mabi=ilp32rv32iaf_zicsr/ilp32f;@march=rv32iaf_zicsr@mabi=ilp32frv32iafc_zicsr/ilp32f;@march=rv32iafc_zicsr@mabi=ilp32frv32iafd_zicsr/ilp32d;@march=rv32iafd_zicsr@mabi=ilp32drv32iafdc_zicsr/ilp32d;@march=rv32iafdc_zicsr@mabi=ilp32drv32ic/ilp32;@march=rv32ic@mabi=ilp32rv32if_zicsr/ilp32f;@march=rv32if_zicsr@mabi=ilp32frv32ifc_zicsr/ilp32f;@march=rv32ifc_zicsr@mabi=ilp32frv32ifd_zicsr/ilp32d;@march=rv32ifd_zicsr@mabi=ilp32drv32ifdc_zicsr/ilp32d;@march=rv32ifdc_zicsr@mabi=ilp32drv32im/ilp32;@march=rv32im@mabi=ilp32rv32ima/ilp32;@march=rv32ima@mabi=ilp32rv32imaf_zicsr/ilp32f;@march=rv32imaf_zicsr@mabi=ilp32frv32imafc_zicsr/ilp32f;@march=rv32imafc_zicsr@mabi=ilp32frv32imafd_zicsr/ilp32d;@march=rv32imafd_zicsr@mabi=ilp32drv32imafdc_zicsr/ilp32d;@march=rv32imafdc_zicsr@mabi=ilp32drv32imc/ilp32;@march=rv32imc@mabi=ilp32rv32imf_zicsr/ilp32f;@march=rv32imf_zicsr@mabi=ilp32frv32imfc_zicsr/ilp32f;@march=rv32imfc_zicsr@mabi=ilp32frv32imfd_zicsr/ilp32d;@march=rv32imfd_zicsr@mabi=ilp32drv32imfdc_zicsr/ilp32d;@march=rv32imfdc_zicsr@mabi=ilp32drv64i/lp64;@march=rv64i@mabi=lp64rv64ia/lp64;@march=rv64ia@mabi=lp64rv64iac/lp64;@march=rv64iac@mabi=lp64rv64iaf_zicsr/lp64f;@march=rv64iaf_zicsr@mabi=lp64frv64iafc_zicsr/lp64f;@march=rv64iafc_zicsr@mabi=lp64frv64iafd_zicsr/lp64d;@march=rv64iafd_zicsr@mabi=lp64drv64iafdc_zicsr/lp64d;@march=rv64iafdc_zicsr@mabi=lp64drv64ic/lp64;@march=rv64ic@mabi=lp64rv64if_zicsr/lp64f;@march=rv64if_zicsr@mabi=lp64frv64ifc_zicsr/lp64f;@march=rv64ifc_zicsr@mabi=lp64frv64ifd_zicsr/lp64d;@march=rv64ifd_zicsr@mabi=lp64drv64ifdc_zicsr/lp64d;@march=rv64ifdc_zicsr@mabi=lp64drv64im/lp64;@march=rv64im@mabi=lp64rv64ima/lp64;@march=rv64ima@mabi=lp64rv64imac/lp64;@march=rv64imac@mabi=lp64rv64imaf_zicsr/lp64f;@march=rv64imaf_zicsr@mabi=lp64frv64imafc_zicsr/lp64f;@march=rv64imafc_zicsr@mabi=lp64frv64imafd_zicsr/lp64d;@march=rv64imafd_zicsr@mabi=lp64drv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64drv64imc/lp64;@march=rv64imc@mabi=lp64rv64imf_zicsr/lp64f;@march=rv64imf_zicsr@mabi=lp64frv64imfc_zicsr/lp64f;@march=rv64imfc_zicsr@mabi=lp64frv64imfd_zicsr/lp64d;@march=rv64imfd_zicsr@mabi=lp64drv64imfdc_zicsr/lp64d;@march=rv64imfdc_zicsr@mabi=lp64dThe 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...

author: martinribelotta
author_rank: Regular Contributor
timestamp: December 24, 2022, 05:26:23 pm
content: Quote from: martinribelotta on December 24, 2022, 05:13:53 pmI found the cause of the miltilib lack...https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/discussions/6When you use the flag--developthis restrict the multilib options due to improve the compilation time.You can remove--developflag 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

author: PavelS
author_rank: Newbie
timestamp: December 26, 2022, 08:56:33 am
content: 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:(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

author: hydrabus
author_rank: Contributor
timestamp: January 05, 2023, 07:12:18 pm
content: Quote from: martinribelotta on December 24, 2022, 05:26:23 pmUpdate:Thanks for the details I have rebuild it seehttps://github.com/hydrausb3/riscv-none-elf-gcc-xpack/releases/tag/12.2.0-1

author: mean00
author_rank: Newbie
timestamp: January 16, 2023, 06:34:00 pm
content: 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 donehttps://github.com/mean00/LLVM-embedded-toolchain-for-rv32.gitIt 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 + picolibcYour 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 libNotice : It takes a while to build

author: paf
author_rank: Regular Contributor
timestamp: January 22, 2023, 11:32:55 am
content: About the CH32V307:There is a nice Chinese development board called Chitu/OpenCH:https://gitee.com/verimaker/opench-ch32v307https://verimake.com/d/37-opench-ch32v307-risc-vYes, 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=PL5k6lPIGwPvQ5SrKA6NajEQSRbbhgoJLgThe CH32V307 is supported by RT-Thread:https://www.rt-thread.io

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2023, 08:26:19 pm
content: 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?)

author: brucehoult
author_rank: Super Contributor
timestamp: October 30, 2023, 09:46:07 pm
content: 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:__attribute__((naked))void my_handler_wrapper(){asm volatile ("call my_handler; mret");}You writemy_handler()as a normal C function.

author: martinribelotta
author_rank: Regular Contributor
timestamp: October 30, 2023, 10:30:53 pm
content: QuoteBe 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/5The 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/59ee16df7b6bf5ebbfa881a79f61dcf67eadb8e9A 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2023, 10:41:30 pm
content: 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:__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.

author: brucehoult
author_rank: Super Contributor
timestamp: October 30, 2023, 11:16:37 pm
content: __attribute__((interrupt))causes the compiler to usemretinstead ofretand 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 anyretetc ... only and precisely code for what you actually write. It's very dangerous.

author: brucehoult
author_rank: Super Contributor
timestamp: October 30, 2023, 11:28:02 pm
content: Quote from: martinribelotta on October 30, 2023, 10:30:53 pmGood 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2023, 11:39:06 pm
content: Quote from: brucehoult on October 30, 2023, 11:16:37 pmYep. 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.Quote from: brucehoult on October 30, 2023, 11:16:37 pmYes, but how do you enable their HPE feature with mainline GCC?Quote from: brucehoult on October 30, 2023, 11:16:37 pmYep. 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?

author: martinribelotta
author_rank: Regular Contributor
timestamp: October 30, 2023, 11:49:36 pm
content: QuoteFor 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

author: brucehoult
author_rank: Super Contributor
timestamp: October 31, 2023, 12:01:54 am
content: Quote from: SiliconWizard on October 30, 2023, 11:39:06 pmI 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/GdcoxPfWfQuoteBy 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.QuoteThe 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.

author: uer166
author_rank: Super Contributor
timestamp: October 31, 2023, 12:07:32 am
content: 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..

author: martinribelotta
author_rank: Regular Contributor
timestamp: October 31, 2023, 12:31:34 am
content: QuoteIs 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 31, 2023, 12:33:48 am
content: Quote from: brucehoult on October 31, 2023, 12:01:54 amI 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: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.Quote from: brucehoult on October 30, 2023, 11:16:37 pmYes 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.Quote from: brucehoult on October 31, 2023, 12:01:54 amYes, 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)?

author: uer166
author_rank: Super Contributor
timestamp: October 31, 2023, 12:38:27 am
content: Quote from: martinribelotta link=topic=322309.msg5143845#msg5143845That 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.

author: brucehoult
author_rank: Super Contributor
timestamp: October 31, 2023, 12:46:41 am
content: Quote from: uer166 on October 31, 2023, 12:07:32 amAs 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  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.https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#111-c-abi-trampoline-code

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 31, 2023, 12:56:26 am
content: Quote from: martinribelotta on October 31, 2023, 12:31:34 amRISC-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.Quote from: martinribelotta on October 31, 2023, 12:31:34 amWell, 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.

author: brucehoult
author_rank: Super Contributor
timestamp: October 31, 2023, 01:04:37 am
content: Quote from: SiliconWizard on October 31, 2023, 12:33:48 amUgh! 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.QuoteCertainly not! That would break all standard RISC-V code.QuoteNO!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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 31, 2023, 01:42:52 am
content: Quote from: brucehoult on October 31, 2023, 01:04:37 amOk, 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/qdc4je3bESo 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:li t0, 0x0bcsrw 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".

author: jnk0le
author_rank: Regular Contributor
timestamp: October 31, 2023, 11:43:39 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 01, 2023, 12:31:32 am
content: Quote from: jnk0le on October 31, 2023, 11:43:39 pmGreat, 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.)

author: brucehoult
author_rank: Super Contributor
timestamp: November 01, 2023, 01:04:19 am
content: Quote from: SiliconWizard on November 01, 2023, 12:31:32 amNote 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 usesmretinstead ofret. 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 01, 2023, 02:36:03 am
content: OK then. No need to bother if that's all they did.Is the prestacked attribute planned for GCC too?

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 14, 2023, 05:15:38 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: November 14, 2023, 06:21:21 am
content: 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 Linkhttps://www.eevblog.com/forum/microcontrollers/flash-and-debug-a-ch32v003-with-only-a-pico-gdb/

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 14, 2023, 09:05:41 am
content: 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-protocolhttps://perigoso.github.io/rins/rvswd/index.htmlBut with missing parts. I'll have a look athttps://github.com/aappleby/PicoRVDto 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.

author: brucehoult
author_rank: Super Contributor
timestamp: November 14, 2023, 10:05:32 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 14, 2023, 09:13:28 pm
content: 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.pdfBut 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.

author: bingo600
author_rank: Super Contributor
timestamp: November 15, 2023, 05:58:24 pm
content: Quote from: SiliconWizard on November 14, 2023, 05:15:38 amI have one in the drawerWould 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 gcchttps://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/TIA/Bingo

author: brucehoult
author_rank: Super Contributor
timestamp: November 15, 2023, 09:03:18 pm
content: Quote from: bingo600 on November 15, 2023, 05:58:24 pmThat's fine.Most sensible OSes have had RISC-V toolchain packages for several years, which you can install using apt, yum, homebrew or whatever.

author: bingo600
author_rank: Super Contributor
timestamp: November 16, 2023, 04:42:51 am
content: Quote from: brucehoult on November 15, 2023, 09:03:18 pmThnxI'm on linux (mint), and wasn't sure about the "guality" of the repos riscv-gccBut 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/mainI 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 compileEDIT:My "kit" came with a wchlink, set for ARM (swd) , not RISC-V , it's the cheap one wo. the buttonsDoes 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 orAnd 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 16, 2023, 05:44:41 am
content: Quote from: bingo600 on November 15, 2023, 05:58:24 pmI 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.)Quote from: bingo600 on November 15, 2023, 05:58:24 pmThat'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:-mabi=ilp32f -march=rv32imafc -ffunction-sections -fdata-sections -msmall-data-limit=8 -mno-save-restore -fmessage-length=0Linker options (LFLAGS):Code:-nostartfiles --specs=nosys.specs --specs=nano.specs \-Wl,-T"$(LINKER_SCRIPT)",-Map=$(MAPFILE),-o"$(TARGETELF)",--print-memory-usage \-Wl,--gc-sectionsLinker script: you can take the "Link.ld" file that is provided in their SDK and just change the memory settings to:Code:FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256KRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64KThe WCH SDK is there:https://github.com/openwch/ch32v307

author: brucehoult
author_rank: Super Contributor
timestamp: November 16, 2023, 08:39:00 am
content: Quote from: bingo600 on November 16, 2023, 04:42:51 amYou use a fork of OpenOCD that knows the WCH protocol.https://github.com/openwch/openocd_wchNo IDE required. Just regular gcc and OpenOCD and WCHLink (or microcontroller such as Pi Pico programmed to emulate one, as pointed to up-thread)

author: bingo600
author_rank: Super Contributor
timestamp: November 16, 2023, 01:08:44 pm
content: Quote from: brucehoult on November 16, 2023, 08:39:00 amRight 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"

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 16, 2023, 11:32:53 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 16, 2023, 11:53:10 pm
content: 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).

author: ataradov
author_rank: Super Contributor
timestamp: November 17, 2023, 02:55:07 am
content: Quote from: SiliconWizard on November 16, 2023, 11:53:10 pmA lot of their documentation is a verbatim copy from the ST documentation.Quote from: SiliconWizard on November 16, 2023, 11:53:10 pmYou probably can, but it is tied to the ARM architecture, so you would not be able to use much past the physical packet format.Quote from: SiliconWizard on November 16, 2023, 11:53:10 pmRISC-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.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 17, 2023, 03:53:51 am
content: Quote from: ataradov on November 17, 2023, 02:55:07 amWell, 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.)

author: ataradov
author_rank: Super Contributor
timestamp: November 17, 2023, 04:03:23 am
content: Quote from: HwAoRrDk on November 17, 2023, 03:53:51 amThey moved the sentences around, but there are a lot of them that are just copyST: "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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 17, 2023, 05:20:23 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: November 17, 2023, 05:42:52 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 17, 2023, 06:08:32 am
content: 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.

author: bingo600
author_rank: Super Contributor
timestamp: November 17, 2023, 11:11:01 am
content: Quote from: SiliconWizard on November 16, 2023, 11:32:53 pmThis one (wchlink R1-1v1) wo. buttons, came with the 32v307 kithttps://www.wch-ic.com/products/WCH-Link.htmlAnd "luckily" got awchlink-e(R0-1v3 w. buttons), when i bought a kit with the small 20-pin ssop'sThey apparently require the wchlink-eSo 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 RVWell .... Seams like it's 2.x$ vs 4.x$ for the E (on ali)/Bingo

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 17, 2023, 11:09:14 pm
content: 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:QuoteSo 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.

author: brucehoult
author_rank: Super Contributor
timestamp: November 18, 2023, 12:26:14 am
content: Quote from: SiliconWizard on November 17, 2023, 11:09:14 pmHit up @patrick_riscv or @wch_tech on Twitter.

author: ddrown
author_rank: Newbie
timestamp: November 18, 2023, 01:48:44 am
content: Quote from: SiliconWizard on November 16, 2023, 11:53:10 pmIn 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 athttps://github.com/ddrown/usbhs-cdc

author: tellurium
author_rank: Frequent Contributor
timestamp: November 19, 2023, 02:32:28 pm
content: Quote from: SiliconWizard on November 14, 2023, 05:15:38 amWould 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.

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 19, 2023, 06:31:14 pm
content: 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

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 19, 2023, 07:08:49 pm
content: Quote from: wilhe_jo on November 19, 2023, 06:31:14 pm..I assume you mean SPI flash - yes, crazy cheap - like under ten cents in small qtys at lcsc

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 19, 2023, 08:18:05 pm
content: Ahhh, yes ... SPI flash...Jlcpcb even has one as a basic part... So no even no fee for pcba.Pretty crazy.73

author: ddrown
author_rank: Newbie
timestamp: November 19, 2023, 08:32:46 pm
content: Quote from: tellurium on November 19, 2023, 02:32:28 pmI've converted a few wch examples to gcc + makefilehttps://github.com/ddrown/CH32V307-makefile-exampleAnd I have the base lwip toohttps://github.com/ddrown/ch32v307-lwip

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 19, 2023, 08:59:43 pm
content: 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

author: jnk0le
author_rank: Regular Contributor
timestamp: November 19, 2023, 10:27:52 pm
content: Quote from: bingo600 on November 17, 2023, 11:11:01 amWCH 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-434682464f8ddc4ea0f0cc856a6c8690edc056d4d46594f9e1a92cc7be262535R1079I'm also hosting windows builds from gpl lettered sources of their fork here:https://github.com/jnk0le/openocd-wch/releases

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 20, 2023, 08:02:20 am
content: Has anyone done ModBUS TCP on this beauty?

author: bingo600
author_rank: Super Contributor
timestamp: November 20, 2023, 01:22:15 pm
content: Quote from: jnk0le on November 19, 2023, 10:27:52 pmDoes that mean the "mode" switchin isretained or forgottenon "dongle reboot" ?I'll be using the dongle onlinux.But might dig up a WIN PC, for the mode switching./Bingo

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 20, 2023, 01:55:31 pm
content: 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

author: tellurium
author_rank: Frequent Contributor
timestamp: November 22, 2023, 10:29:05 am
content: Baremetal Makefile project for ch32v307 with Mongoose library is ready and working:https://github.com/cesanta/mongoose/tree/master/examples/wch/ch32v307-make-baremetal-builtinSome facts:1. The firmware code (not counting toolchain/sdk files), is only 5 files including headers2. Mongoose implements the whole networking engine (drivers, TCP/IP stack, HTTP/Websocket/MQTT/SNTP.. lib) in a single file3. In main.c, all network-related code that sets up ethernet, TCP/IP, and implements a web server, is ~20 lines4. 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 & make2. Install riscv toolchain, e.g. on Mac `brew install riscv-gnu-toolchain`3. clone mongoose repo: git clonehttps://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 converter6. Observe logs, look at the obtained IP address (see below for logs example)7. Point your browser at that IP address412 2 net_builtin.c:197:onstatechang READY, IP: 192.168.2.78417 2 net_builtin.c:198:onstatechang GW: 192.168.2.141d 2 net_builtin.c:199:onstatechang MAC: 02:38:9a:a3:39:e3423 2 main.c:107:main Initialising application...429 3 net.c:195:mg_listen 1 0http://0.0.0.042e 2 main.c:110:main Starting event loop7dd 2 main.c:35:timer_fn Ethernet: ready, IP: 192.168.2.78, rx:4, tx:3, dr:0, er:0bc5 2 main.c:35:timer_fn Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0fad 2 main.c:35:timer_fn Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0

author: brucehoult
author_rank: Super Contributor
timestamp: November 22, 2023, 11:19:57 am
content: Quote from: tellurium on November 22, 2023, 10:29:05 amNice!How is the code size?

author: tellurium
author_rank: Frequent Contributor
timestamp: November 22, 2023, 11:35:56 am
content: Quote from: brucehoult on November 22, 2023, 11:19:57 amAround46k on flash-rwxr-xr-x 1 cpq staff 47220 22 Nov 04:36 firmware.binRAM footprint:1. Driver DMA descriptors: 1540 * NUM * 2. NUM is 4 currently, total 12320 bytes2. Send buffer 1540 bytes3. Receive queue 8k4. 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 usageSummary:a) TCP/IP stack eats about20k of RAM (can be tuned down twice the size, down to 10k)b) each connection eats about4k (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 thishttps://mongoose.ws/device-dashboard/would take:a) Copying extra 3 files to the source treeb) Increase on flash footprint~50k

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 23, 2023, 03:16:35 am
content: How does it compare to lwIP?

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 23, 2023, 12:13:20 pm
content: QuoteThanks for sharing, does you lib support modbus too?

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 23, 2023, 09:46:55 pm
content: 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.)

author: tellurium
author_rank: Frequent Contributor
timestamp: November 24, 2023, 09:04:58 am
content: Quote from: SiliconWizard on November 23, 2023, 03:16:35 amThat 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 taskI'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 5shttp://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 MongooseRequests per second 3 16 286 1080Firmware size 117k 160k 114k 28kI 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.

author: tellurium
author_rank: Frequent Contributor
timestamp: November 24, 2023, 09:44:30 am
content: Quote from: ali_asadzadeh on November 23, 2023, 12:13:20 pmThe 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?

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 24, 2023, 11:15:28 am
content: QuoteIt 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 24, 2023, 11:30:26 pm
content: Quote from: tellurium on November 24, 2023, 09:04:58 amThanks, those results look pretty impressive. Basically a no-brainer. What's the catch with Mongoose if any?

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 24, 2023, 11:39:01 pm
content: Just a note regarding the official SDK for the CH32V3xx, that can be found here:https://github.com/openwch/ch32v307There'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.

author: jnk0le
author_rank: Regular Contributor
timestamp: November 25, 2023, 02:04:53 am
content: Quote from: bingo600 on November 20, 2023, 01:22:15 pmI think its not persistent.One more thing you could try is minichlinkhttps://github.com/cnlohr/ch32v003fun/tree/master/minichlink, not sure how it handles this button less module.

author: bingo600
author_rank: Super Contributor
timestamp: November 25, 2023, 08:44:29 am
content: Quote from: jnk0le on November 25, 2023, 02:04:53 amThat'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

author: tellurium
author_rank: Frequent Contributor
timestamp: November 25, 2023, 04:55:26 pm
content: Quote from: SiliconWizard on November 24, 2023, 11:30:26 pmHere'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).

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 26, 2023, 08:46:00 am
content: tellurium thanks for sharing, Please add instruction on installing the compiler and debugger tool on win11 for ch32v307 in your website or here.

author: bingo600
author_rank: Super Contributor
timestamp: November 26, 2023, 10:08:21 am
content: Quote from: ali_asadzadeh on November 26, 2023, 08:46:00 amI found , that compiler inst. were documented here (ARM) ... So just replace "compiler inst w. Risc-Vhttps://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 makefileUsing linux.

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 26, 2023, 04:06:27 pm
content: 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

author: tellurium
author_rank: Frequent Contributor
timestamp: November 26, 2023, 07:13:43 pm
content: Quote from: wilhe_jo on November 26, 2023, 04:06:27 pmAgain 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?

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 26, 2023, 08:37:23 pm
content: Well, for quite some applications, the memory is not really a big problem.If you think the ch32v307 seems odd, look at this one: CH569ATM, 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 26, 2023, 09:44:26 pm
content: Quote from: tellurium on November 26, 2023, 07:13:43 pmIt'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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 27, 2023, 09:02:01 am
content: Thanks for the update, I have followed the instruction with theseI opened the git bash in the wch project directory and typed like thisQuoteIt went okafter 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 pathnow I can UseQuotein git bash and it would print like thisQuoteNow when I tpye make in the wch project I would get this errorsQuoteI tried to modify the make file to thisCode:CFLAGS = -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotionCFLAGS += -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversionCFLAGS += -ffunction-sections -fdata-sections #-fmessage-length=0 -fsigned-charCFLAGS += -march=rv32imafc -mabi=ilp32f #-msmall-data-limit=8 -mno-save-restoreCFLAGS += -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os $(CFLAGS_EXTRA)LDFLAGS = -T vendor/link.ld -nostartfiles --specs=nano.specs #--specs=nosys.specsLDFLAGS += -lc -lgcc -Wl,--gc-sections #-Wl,-Map=$@.mapSOURCES = main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.Sifeq ($(OS),Windows_NT)RM = cmd /C del /Q /F /SelseRM = rm -rfendifall: firmware.binfirmware.bin: firmware.elfriscv-none-elf-objcopy -O binary $< $@ls -l firmware.*firmware.elf: $(SOURCES) hal.h Makefileriscv-none-elf-gcc $(SOURCES) $(CFLAGS) $(LDFLAGS) -o $@flash: firmware.binwchisp flash $<clean:$(RM) firmware.* *.suand I get this errorQuote

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 27, 2023, 09:03:48 am
content: QuoteWch has come to destroy some ARM chips including STM32 with its insane prices!

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 27, 2023, 09:35:22 am
content: Quote from: ali_asadzadeh on November 27, 2023, 09:02:01 amI 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.

author: martinribelotta
author_rank: Regular Contributor
timestamp: November 27, 2023, 12:11:59 pm
content: QuoteThis 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/104592The correct way to solve this is add to environment variables a system-wide temporary directory like C:\temp

author: tellurium
author_rank: Frequent Contributor
timestamp: November 27, 2023, 09:30:18 pm
content: Quote from: ali_asadzadeh on November 26, 2023, 08:46:00 amI'll start a separate topic for ch32v307 modbus console, to avoid polluting this topic.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 28, 2023, 06:23:23 am
content: 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.)

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 28, 2023, 10:19:41 am
content: 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

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 28, 2023, 07:51:03 pm
content: Quote from: SiliconWizard on November 28, 2023, 06:23:23 amIf 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 28, 2023, 10:13:35 pm
content: 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.

author: tellurium
author_rank: Frequent Contributor
timestamp: November 28, 2023, 10:19:00 pm
content: Quote from: SiliconWizard on November 28, 2023, 06:23:23 amThe 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-CH32V307RCCH32V30x_D8 - CH32V303VC-CH32V303RCFLASH + RAM supports the following configurationFLASH-192K + RAM-128KFLASH-224K + RAM-96KFLASH-256K + RAM-64KFLASH-288K + RAM-32K*/FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 288KRAM (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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 29, 2023, 12:06:20 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 29, 2023, 08:20:12 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: November 29, 2023, 08:58:58 am
content: 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..

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 29, 2023, 09:21:05 am
content: 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

author: iMo
author_rank: Super Contributor
timestamp: November 29, 2023, 09:32:03 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: November 29, 2023, 10:02:23 am
content: Quote from: iMo on November 29, 2023, 08:58:58 amI think you're thinking of Gigadevice and the GD32VF103 and also Arm version.QuoteThat'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.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 29, 2023, 11:00:33 am
content: Quote from: wilhe_jo on November 29, 2023, 09:21:05 amI 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...

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 29, 2023, 11:18:16 am
content: Quote from: HwAoRrDk on November 29, 2023, 11:00:33 amWell, non-documented does not mean non-existing, but may imply non-functional...Quote from: SiliconWizard on November 28, 2023, 10:13:35 pmBack 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 important73

author: iMo
author_rank: Super Contributor
timestamp: November 29, 2023, 11:41:04 am
content: Quote from: brucehoult on November 29, 2023, 10:02:23 amYep, you are right..Anyhow, simply send a chip to Noopy and we get more on the setup..

author: bingo600
author_rank: Super Contributor
timestamp: November 29, 2023, 01:55:28 pm
content: Quote from: jnk0le on November 25, 2023, 02:04:53 amI found a Win10 PC , and used : WCH-LinkUtility to switch mode on my "Buttonless" WCHLINK to RiscV modeIt 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-EAccording to Doc , you need the WCHLINK-E to program the small 20-pin ssop, but both can program a 307Edit: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

author: bingo600
author_rank: Super Contributor
timestamp: November 29, 2023, 03:27:30 pm
content: There's a bit of definitions in the : WCHISPTool_CMD.ZIP - Commandline programmerSome source and API headers , but the "Goodies" is in a library w. no srcMaybe someone can deduct some info from the API include filesI'm especially thinking how2 set flash/mem partitioning on linux.Seems like the "Config file" needed can be made/saved in theQuote/Bingo

author: jnk0le
author_rank: Regular Contributor
timestamp: November 29, 2023, 07:20:13 pm
content: Quote from: bingo600 on November 29, 2023, 01:55:28 pmDoes it remain when moved to linux pc, or just the driver?

author: bingo600
author_rank: Super Contributor
timestamp: November 29, 2023, 08:27:07 pm
content: Quote from: jnk0le on November 29, 2023, 07:20:13 pmIt reprograms the programmer.And it remains RiscV - When moved/connected to linuxEdit:My wchlink programmer also registers as an usb uartttyACM0Helps a lot with an uart for messages.Might be why there was a ch3xx Win driver included.Linux doesn't need a driver.

author: bingo600
author_rank: Super Contributor
timestamp: November 29, 2023, 08:27:46 pm
content: ddrown wrote something interesting about the flash/ram partitioning herehttps://github.com/cnlohr/ch32v003fun/issues/232#issuecomment-1694923415Edit ....Based on that (3f,ff,bf,7f)Code:128k.txt:81:06:08:02:3f:ff:ff:ff:ff:ff:ff32k.txt:81:06:08:02:ff:ff:ff:ff:ff:ff:ff64k.txt:81:06:08:02:bf:ff:ff:ff:ff:ff:ff96k.txt:81:06:08:02:7f:ff:ff:ff:ff:ff:ffIt could be that this command (two upper bits) controls a 64K (bit 7 = 0) and 32K (bit 6 = 0) Ram bankIf theMCU always has 32K Ram, then you can switch in an extra 64K and/or 32K by setting the cooresponding bit to ZEROI have no idea (yet) if these are MCU register bits or Programmer "instructions

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 29, 2023, 09:04:47 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 29, 2023, 09:52:53 pm
content: * 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:>RAM AT>FLASH, as for the .data section.I think this is pretty wrong. It should be onlyCode:>RAMas 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.

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 29, 2023, 11:23:25 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 30, 2023, 12:57:53 am
content: Quote from: wilhe_jo on November 29, 2023, 11:23:25 pmIt'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.

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 30, 2023, 06:44:34 am
content: Quote from: SiliconWizard on November 30, 2023, 12:57:53 amThat'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

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 30, 2023, 08:26:28 am
content: Quote from: SiliconWizard on November 29, 2023, 09:52:53 pmI'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 besomethingin it".

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 30, 2023, 08:53:59 am
content: 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:FLASH_NZW (rx) : ORIGIN = 0x08000000 + LENGTH(FLASH), LENGTH = 480K - LENGTH(FLASH)Then add a section like this:Code:.flash_nzw_data :{. = ALIGN(4);*(.flash_nzw_data). = ALIGN(4);} >FLASH_NZWAnd 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.

author: tellurium
author_rank: Frequent Contributor
timestamp: November 30, 2023, 12:15:56 pm
content: Quote from: SiliconWizard on November 29, 2023, 09:52:53 pmCorrect. BSS should not occupy any space in the compiled binary, and should not take any space on flash.

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 30, 2023, 12:49:05 pm
content: Quote from: SiliconWizard on November 30, 2023, 08:53:59 amIIRC, 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

author: bingo600
author_rank: Super Contributor
timestamp: November 30, 2023, 02:49:29 pm
content: I have just "enhanced" minichlink (for the wchlink(-e) dongle) with ram partitioning - On programming.Thanx to ddrown for doing the hard work.See attachmentsI have only tested 64K Ram for now.That's what ddrown's lwip example uses in the linker./Bingo

author: wilhe_jo
author_rank: Regular Contributor
timestamp: November 30, 2023, 03:24:11 pm
content: <edit>ok.. I played around... it may really, really work...I added a mapped section:Code:MAPPED(rx) : ORIGIN = 0x00000000, LENGTH = 288KFLASH (rx) : ORIGIN = 0x08000000, LENGTH = 480KRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32KThen I switched ">FLASH AT>FLASH" to ">MAPPED AT>FLASH"next, I switched the openocd stuffCode:#interface wlinkadapter driver wlinkeadapter speed 3000transport select sdiwlink_set_address 0x08000000set _CHIPNAME wch_riscvsdi newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x00001set _TARGETNAME $_CHIPNAME.cputarget create $_TARGETNAME.0 wch_riscv -chain-position $_TARGETNAME$_TARGETNAME.0 configure -work-area-phys 0x20000000 -work-area-size 10000 -work-area-backup 1set _FLASHNAME $_CHIPNAME.flashflash bank $_FLASHNAME wch_riscv 0x08000000 0 0 0 $_TARGETNAME.0echo "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

author: bingo600
author_rank: Super Contributor
timestamp: December 01, 2023, 05:12:16 am
content: 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

author: brucehoult
author_rank: Super Contributor
timestamp: December 01, 2023, 06:32:40 am
content: Quote from: bingo600 on December 01, 2023, 05:12:16 amThis issue has been extensively discussed here in the past.If you are going to call such a heavyweight thing asprintf()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 theprintf()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* thatprintf()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 instructionsjal, andret.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.

author: wilhe_jo
author_rank: Regular Contributor
timestamp: December 01, 2023, 07:42:52 am
content: QuoteHmmm this must be the reason for using softfp as the default...Regards

author: martinribelotta
author_rank: Regular Contributor
timestamp: December 01, 2023, 02:28:33 pm
content: QuoteWhile 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=ilp32fbut 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"

author: wilhe_jo
author_rank: Regular Contributor
timestamp: December 01, 2023, 09:38:37 pm
content: 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 architectureAll 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

author: brucehoult
author_rank: Super Contributor
timestamp: December 01, 2023, 10:19:31 pm
content: Quote from: wilhe_jo on December 01, 2023, 09:38:37 pmTechnically, 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.QuoteLLVM 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-llvmMany 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)

author: bingo600
author_rank: Super Contributor
timestamp: December 02, 2023, 06:48:08 am
content: openvch just updated EVT sdk,boards & schematicshttps://github.com/openwch/ch32v307

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 02, 2023, 11:10:08 am
content: Quote from: martinribelotta on December 01, 2023, 02:28:33 pmIf you're using FP in an interrupt handler you're probably doing things wrong.

author: wilhe_jo
author_rank: Regular Contributor
timestamp: December 02, 2023, 07:49:09 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 02, 2023, 10:08:57 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: December 02, 2023, 11:17:22 pm
content: Quote from: SiliconWizard on December 02, 2023, 10:08:57 pmIf 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 usesmretinstead ofret(and possibly also doesn't saveraif another function is called) or as "__attribute__((interrupt))that doesn't savera,a0-a7,t0-t6".A comment by martinribelotta appears to indicate it is the latter.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 02, 2023, 11:21:17 pm
content: 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?

author: brucehoult
author_rank: Super Contributor
timestamp: December 03, 2023, 12:37:53 am
content: Quote from: SiliconWizard on December 02, 2023, 11:21:17 pmThey'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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 03, 2023, 11:45:14 pm
content: Quote from: brucehoult on December 03, 2023, 12:37:53 amI 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?)

author: brucehoult
author_rank: Super Contributor
timestamp: December 04, 2023, 12:11:52 am
content: Quote from: SiliconWizard on December 03, 2023, 11:45:14 pmFFS. 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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 06, 2023, 08:21:17 am
content: Quote from: brucehoult on December 04, 2023, 12:11:52 amNot 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.

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2023, 09:13:42 am
content: Quote from: SiliconWizard on December 06, 2023, 08:21:17 amNothing to do with gcc specifically, just standard software development practices.QuoteYes, of course.QuoteYes, of course.QuoteNothing to do with gcc, just standard software development practices.QuoteYes, 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.QuoteThe question is: is "WCH-Interrupt-fast" more similar to standard C functions (just replace `ret` with `mret`), or is it more similar to "Interrupt"?QuoteNothing 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).QuoteNo knowledge of gcc required, just standard software development practices.QuoteOf course. And of course it does not break existing behaviour, as I've said repeatedly. Why would it? That would be stupid.QuoteNo. 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.QuoteI 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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: December 07, 2023, 01:04:07 pm
content: 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

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: December 07, 2023, 03:29:42 pm
content: 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 theDelay_Ms and Delay_Us functions in debug.c file like thisQuote

author: jnk0le
author_rank: Regular Contributor
timestamp: December 08, 2023, 12:29:27 am
content: Code: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.

author: brucehoult
author_rank: Super Contributor
timestamp: December 08, 2023, 12:55:03 am
content: Quote from: jnk0le on December 08, 2023, 12:29:27 amAddingasm 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:.L3:addi a5,a5,1bne a5,a0,.L3ret... but with-Os...Code:.L2:bne a0,a5,.L3ret.L3:addi a5,a5,1j .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.

author: Sueco
author_rank: Contributor
timestamp: January 19, 2024, 12:27:29 pm
content: 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:FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 288KRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32KROM (r) : ORIGIN = 0x00048000, LENGTH = 192KOf course this could be easily altered to any of the available combinations 256K+64K, leaving 224K for ROM, etcI removed .rodata from .text:Code:.text :{. = ALIGN(4);*(.text)*(.text.*)*(.gnu.linkonce.t.*). = ALIGN(4);} >FLASH AT>FLASHAnd defined a new section .constants:Code:.constants :{. = ALIGN(4);*(.rodata)*(.rodata*). = ALIGN(4);} >ROMThis 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 19, 2024, 12:31:50 pm
content: Quote from: brucehoult on December 08, 2023, 12:55:03 amfor(i=0;i<p_us*n;i++) asm("nop");will work

author: HwAoRrDk
author_rank: Super Contributor
timestamp: January 19, 2024, 08:33:29 pm
content: Quote from: Sueco on January 19, 2024, 12:27:29 pmI'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.

author: brucehoult
author_rank: Super Contributor
timestamp: January 19, 2024, 08:42:28 pm
content: Quote from: HwAoRrDk on January 19, 2024, 08:33:29 pmThat 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.

author: bingo600
author_rank: Super Contributor
timestamp: February 02, 2024, 03:55:50 pm
content: I just had a headscratcher with some new ch32v307 boardsI got a few of these boards - Andthey came with flash protection enabled from the factory.https://www.aliexpress.com/item/1005004350410929.htmlSince i was lazy and wanted to use DFU Programming , i had to do some trickery to solve that.See herehttps://www.eevblog.com/forum/microcontrollers/ch32v307-modbus-web-ui-firmware/msg5312677/#msg5312677/Bingo

author: LM2023
author_rank: Newbie
timestamp: April 22, 2024, 12:57:19 pm
content: Quote from: bingo600 on November 29, 2023, 08:27:46 pmHere you can find an excellent description of V20x and V30x versions that have "reconfigurable" ram/flash mapping:https://github.com/cnlohr/ch32v003fun/issues/280You 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 areinitialized at resetby 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 toconfigure 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)]00128KB192KB288KB0196KB224KB256KB1064KB256KB224KB1132KB288KB192KBEdit: Got the register <--> option bytes dependency wrong, corrected it and added more details.

author: John Celo
author_rank: Regular Contributor
timestamp: April 23, 2024, 12:36:11 am
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: April 23, 2024, 12:59:52 am
content: Quote from: John Celo on April 23, 2024, 12:36:11 amWhere 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.

author: mean00
author_rank: Newbie
timestamp: May 11, 2024, 06:51:43 am
content: Shameless ad :For fun i did a port of the blackmagic probe that does support the CH32V303/305/307 (the CH32V2xx are sort of supported, but lack of hw breakpoint makes them hard to use)It can run on RP2040, and since it is a blackmagic derivative there is nothing to install / to runIt is a bit slow due to the protocol used, but works wellThe only main difference with normal arm based blackmagic is "mon swdp_scan" is to be replaced by "mon rvswdp_scan" to find the CH32Vxx chipsThere is a uf2 available at github.com/mean00/swindle

author: martinribelotta
author_rank: Regular Contributor
timestamp: May 11, 2024, 03:01:18 pm
content: QuoteWow! Thats great!!!! An rp2040 debugging an ch32v chips enables a full FLOSS workflow for this chips!!!If I understand correctly, this enables a ch32v3x chip to debug an other ch32v3x chip using BMP firmware... Its true?Did you reverse engineer the Rvswd protocol?Congratulations and good work!!!

author: brucehoult
author_rank: Super Contributor
timestamp: May 11, 2024, 08:46:04 pm
content: Quote from: martinribelotta on May 11, 2024, 03:01:18 pmWhy reverse engineer when it's 1) fully documented, and 2) the source code of their modified openocd is published?

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 11, 2024, 09:32:52 pm
content: Quote from: John Celo on April 23, 2024, 12:36:11 amApples and oranges. What does "stack well" mean here? You're comparing something which is basically between a Cortex M0 and M4 in terms of performance to a Cortex M7, which is eons above in terms of computing performance, has 8 to 16 times the RAM (depending on config). It's a completely different beast. Cost is about 4 times more.Comparing doesn't make much sense, unless you're specifically picking a Cortex-M7 MCU to get USB HS and an Ethernet MAC, which is more uncommon with lower-end MCUs, and don't need the performance. Then the CH32V30x fits a nice spot that I do find useful.

author: martinribelotta
author_rank: Regular Contributor
timestamp: May 12, 2024, 03:47:34 am
content: QuoteIn my knowledge, the only documented protocol is SDI 1-wire used on ch32v003 series, not the SWD-alike (CK+DIO) used by others chips of this series...The openocd code is very high level (this delegate various commands to the dongle). This can made help about the steps to seek in high level but many actions is performend at dongle levelIn my understand, the SDI 1-wire protocol is the same to 2-wire protocol used by ch32v30x in transaction layer but is TBD for my... When I have time, will try this code and investigate more about it

author: brucehoult
author_rank: Super Contributor
timestamp: May 12, 2024, 09:29:27 am
content: Quote from: martinribelotta on May 12, 2024, 03:47:34 amoops, my mistake.

author: mean00
author_rank: Newbie
timestamp: May 12, 2024, 01:10:45 pm
content: Hi,The RVswd is not fully documented and has not been completely reverse engineered.Perigoso on github did a part of the job, and i replayed a capture of a wchlink until it worked.What has been RE is the protocol to talk to the WCH link, and then the WCH link converts to RVSWD.My RE is not 100% correct/complete, but "good enougth", i.e. it works.and yes, swindle works on a RP2040, GD32F303 and CH32V3XX so you can use a CH32V30x to debug another oneThere is a small kicad PCB in the kicad folder to do just that (use a CH32V303RCT6 to debug CH32V3xx)I like a lot the CH32V3XX family (especially the CH32F303RCT6) . It is fast, the FPU & fast interrupt helps a lot, mostly compatible with STM32F103 and cheap.It has a couple of annoying quirks :There is no watchpoint (i.e. break on read/write/access) (no breakpoint at all on the CH32V2xx, unusable)The RVSWD protocol is a bit slow. If you deal with huge executable uploading them through DFU then debugging it is faster.

author: mean00
author_rank: Newbie
timestamp: May 12, 2024, 01:30:48 pm
content: If it is of interest i can upload the swindle binary for CH32V3xxYou'll have to upload the bootloader through wchlink and then you can upload the main app over USB ( USB DFU)BTW, one of the thing i didnt like about the openocd/wchlink port, is that it erases the whole flash, so that raises problem when you use a custom bootloader.