SWIO program/debug for CH32V003

Someone dropped this on Twitter. It’s a command line debug interface to CH32V003, a 10 cent RISC V processor. The chip uses a single wire protocol that looks a lot like 1wire but I haven’t checked the timings.

Adding an integration to my to-do list.

Does anyone nearby (EU) have one of these chips I could have?

I bought 50 on Ali express but I imagine theyll take some time getting here. I’m happy to share some if anyone wants to follow along.

1 Like

@Taniwha mentioned on Twitter that using the ch32 debug while also using I2C would be helpful.

I’m trying to sketch out an interface that’s intuitive.

Maybe a “toolbox” concept with various utilities that can be applied to pins regardless of modes? Debuggers, programmers, flash loaders and dumpers. Right now the closest concept we have is frequency generation and frequency measurement, which have their own commands. Maybe the toolbox could be shaped by a collection of PIO programs that can be loaded.

Something to think about: VT100 has a secondary frame buffer. This is a second “screen” that pops over the main output. It’s not scrollable, just one page. Maybe we can use it for a more complex menu system, and use the ASCII frame characters for a proper 1980s drop down menu feel.

1 Like

I got this project compiling. It’s CPP though, so a direct integration is a big project.

Installing this now.

I’m not sure this is in the category of tools, but what would be useful to me is a “sanity check” before some of the modes. For instance, if I wire up a UART port and it tells me the RX/TX pins are 5V (Oops!) Same with JTAG/SWD/12C/SPI. Or suppose I want to read some flash memory (using a SOIC8 clip), and it tells me one of the pins is in the wrong state. I know the voltages are displayed, but sometimes people make mistakes. Not me. Nope. Never happened.

1 Like

I like that idea. There is definitely a need to handle bus states in a consistent way with reality checks. Especially initial state. For example spi clock levels, but also i2c levels.

In I2C there is an issue with devices holding the line after error (not usual in normal use, but a constant in prototyping), this stops the I2C peripheral from resetting properly. The solution is that we run hard reset three times after an error condition to recover.

Perhaps a reference start point for all pins, and if they don’t match 1. Issue error, 2. Attempt auto recover. 3. If auto recover doesn’t work, suggest user intervention .

I love it! And the best warning/error messages suggest possible fixes to the problem.

so for a chv32 I think the thing you should be trying to do is to be workalike with the dongle people are already using - I’m using a linux program wlink that talks to that dongle (that should give you the protocol on the computer <->dongle side) it’s here: GitHub - ch32-rs/wlink: An open source WCH-Link library/command line tool written in Rust.

I kind of think you’re right about modes and protocols: I should be able to set up i2c on these pins and software download of a particular type on those and maybe a 3rd on some other pins - somethings like software download/debug might want to use their own usb channel because they’ll have their own protocols

Good call. Ch32v003fun is great, but more importantly, tha author is brilliant and easy to work with. He runs a discord that probably has a higher concentration of participating '003 HW/SW nerds than the one by WCH themselves.

If you run into square pegs not fitting needed round holes and need advice or help filing them off, GitHub reports are monitored, but I think more eyes are reached in his channel. Those posters and readers are very much the audience if this product. (I’ll probably order after new year dust settles and US distribution works.)

Sorry if this sounds like a promo. I’m just a happy user /developer and since discord is a stinking unsearchable walled garden, though it might not show up in even a thorough web search, thought I’d toss. Out a personal recommendation.

cnlohr_projects is Charles’ and covers many of his. Related. Problems.

https://twitter.com/patrick_riscv/status/1514413606095720448 also mentions three of the best EE type people on Xitter (well. Mastodon now) to follow… these discords cover some of the arm/8051 parts but the focus now really is on all the WCH32[VX][0123]0[357] SoCs plust their billion “USB to something tha5. Needs a little bit-banging in silicon to some goofy front-end” parts.

For anyone tinkering with the new generations of WCH,. These are two great discords (oxymoron duly noted) to follow.

1 Like

Thank you for the resources and recommendations. I got ch32v003fun up and running. I can implement the arduino compatible debug interface pretty easily, it just pushes and pulls from addresses. I’m really keen to start working on this one.

1 Like

Cool! It’s a nifty family of parts (esp for .10. - I got a handful of freebies with a related order) and Fun really takes the sharp edges off of them.

The whole line of, basically, STM32 clones with Risc-V cores is pretty groovy but the tiny parts really do fill a unique hole in the industry. 8051 asm vs $0.10 32-bit c or c++ from a mainlined GCC or Clang? Easy choice! Anything that needs to go “down” from esp32 get first crack from WCH in my hobbyist designs these days.

I look forward to joining the BP5 family soon. I’m hoping it can replace a lot of throwaway “getting to know this peripheral” code on Nuttx (half my code ends up fighting Nuttx) or FTDI Friend (user space libraries never seem to work well) or whatever. Bring a scripting interface, LA, decoder, scope, JTAG ws281b in24 amd 32 bit forms, and everything else in one set of cables just sounds :cherries:! Thank you.

Oooh, not to hijack, but that’s a fun thought. A scriptable, timestamped. Ws281x Receiver would Solve some. Interesting problems for me. PIO should be able. to do clock recovery and sampling at 800khz and just store 400 (whatever) RGBWs between EOFs to be picked up by a Real Computer later. Most successive pixels are similar color,.so even a simple Run Length compression may make it fit in the slow USB in nearly runtime. Additionally, most successive frames are similar to each other… I may have just talked myself into a project before even ordering one

Hack on!

I have not done something that complex with PIO, but I believe there is a Manchester encoding example in the SDK that may have the basic components.

Pushing through the USB is of course nice, but it probably requires crapware on the PC side. Logging to internal flash (and be drag and dropped out from the USB disk interface) or just an on screen explorer might be a less involved to handle that data. We really do need a basic nano/vim and hex edit tool that can be used straight from the Bus Pirate.

No crapware needed. In my case, id be happy with a stream of ASCII hex of each RGB (maybe RGBW) value if the data fit the time slice. Even throwing away every other pixel or some such subsample would still be huge for those developing led software that don’t want to test with miles of lights. The pio would have to keep count as there isn’t a “start bit” per byte. Once the drummer starts,. It’s one bit per N clocks. (Corrupting one bit is what turns these strings into a flickering mess.)

This is perhaps getting OT, but stuffing something approximately like

Into the project could be awesome. (Of course, seeing that project, I see it could also be done without BP but integrating it into sigrok and pairing it with a scriptable output would be big for this (tiny) market of devs. I just don’t really have a concept of how much headroom 2040 has while slurping an unforgiving 800Khz sample rate. Drift . 5% on a 10px strand is not big deal, but by the end of a. 1000px strand, you’re sampling the wrong sub-frame. The pio thing could probably bit bang (is the receiver version “bit slurp” or something? Since the strings can be long and the protocol is rarely able to be decoded and dmaed straight into ram.

Someone needs to do this (implement Neopixel receive) and I think it’s within my reach. I think I just talked myself into a project and will add one of these to my wish list. I’d thought about doing this with 'v003, but 2040 is such a better xhoice.

Oh, and of course, Bus Pirate needs HUB75 bus decoders. Later. I need that less. Unit testing Neopixel (et al) against known reference streams or renderinfg them into a web view for documentation would be lovely.

So I’m interested in helping with a ws2812 decoder, which I’m pretty sure we can pull off for at least a short strand and see where it goes from there.

(and the other message that was eaten by the mail response handler)

Re: hex dump and file editing.

Do we have curses? I’ve done tiny hex editors and vim clones in the past. I guess if you just nail the requirement to vt100 80x25, even building a “raw mode” curses (no FMLI) insnt THAT hard… Do the files all fit in RAM/mappings or do they need to be demand-paged?

If you’re willing to coach the design a little (e.g. “we don’t care about your VT-52 or ADM-3a”, " here’s how to do live monitoring without destroying the bus", “we officially don’t car about libe reload”, " file locking is critical ", etc.) I’m willing to do the carpentry on some features like that.

Sounds like we should indeed be friends.
I’d like to build a ws281x receiver.
I have relevant experience building file viewers and implementing “enough” of vi keystrokes in places where it “should not go” like kernel debuggers. Id help build either or both., esp if you have designs and/or UX mocks . (“Hexdump -C. Done”. Works for me…)

Show quoted text

Wow, that ws2812 emulator is awesome! It is definitely on my list to add. One nice thing is we have the 5v buffers to level shift both ways.

Curses is a good question! I have no idea if there is a simple C curses for arm GCC. I don’t see why there shouldn’t be, but I’ve never come across it. If it ran in the 80’s RAM shouldn’t be an issue.

curses/ncurses was complicated because it supported ANY terminal. If you assume a vt100-compatible, this would simplify things a bit. Instead of operation->database->escape code, you could eliminate the database in the middle. I found this simplified library for ARM devices. It might help. GitHub - infinnovation-dev/incurses: Minimal ncurses implementation for use in embedded environments

BTW, there may be other benefits. I noticed a few cases where the toolbar and typing confused the display and it was garbled. In the display command, you could add an option to clear the display.

1 Like

Good find! It also supports a tiny emacs text editor:

If there’s a similar hex editor script I’d be thrilled

I would really appreciate this! have a bunch of this chips laying around.

1 Like