My alpha Pico-based CH32V003 debug tool is ready for a few testers | Hacker News Reader

My alpha Pico-based CH32V003 debug tool is ready for a few testers

github.com

58 pointsaappleby26 comments

The CH32V003 is a 10-cent RISC-V microcontroller with a proprietary single-wire debug interface and a corresponding proprietary debug dongle + modified version of OpenOCD.

My tool replaces the dongle and OpenOCD with a Pico-based GDB remote host. You can debug and flash a CH32V003 with just a Pico, one pull-up resistor, and gdb-multiarch.

Basic testing on the included example app seems to work, and the code should be stable enough to handle a few testers. If you're interested in the CH32V003 and have a Pico on hand, give it a try.

-Austin

Thank you for this work, Austin. I was looking to try CH32V003, but I was unsure about the toolchain. Thank you for making it better.

Edit: any recommendations of a CH32V003 dev board?

The official dev boards are available on AliExpress for under $10. You can also get them off Tindie, I believe.

Thanks! Ordered.

For the benefits of others, these are the product pages on Aliexpress and Tindie:

https://www.aliexpress.us/item/3256804778040328.html

https://www.aliexpress.us/item/3256804801806865.html

https://www.tindie.com/products/adz1122/ch32v003-risc-v-mcu-...

Also on AliExpress from the manufacturer - https://www.aliexpress.com/item/1005005269690018.html

Er, wait no this link - https://www.aliexpress.us/item/3256804709476544.html

Oh, thx! Sadly, I can't edit my original comment above.

Very cool! For now, I'm using the PY32F002A for my low-cost MCU needs, but if this project was around a few months ago, I would have had to think harder about it.

I like that you've included a GDB server directly in the project, I've had way too much trouble getting a version of openocd that works properly for my pico projects, and now that's just cut out of the picture :)

The bigger brother chip is the CH32V307VCT6

AUD$20 https://www.ebay.com.au/itm/304645792686

https://github.com/openwch/ch32v307

    RISC-V4F processor, max 144MHz system clock frequency;
    Single-cycle multiplication and hardware division, hardware float point unit (FPU) ;
    64KB SRAM，256KB Flash;
    Supply voltage: 2.5V/3.3V, GPIO unit is supplied independently;
    Multiple low-power modes: sleep/stop/standby;
    Power-on/power-down reset (POR/PDR), programmable voltage detector (PVD);
    2 general DMA controllers, 18 channels in total;
    4 amplifiers;
    Single true random number generator (TRNG)
    2 x 12-bit DAC;
    2-unit 16-channel 12-bit ADC, 16-channel TouchKey;
    10 timers;
    USB2.0 full-speed OTG interface;
    USB2.0 high-speed host/device interface (built-in 480Mbps PHY)
    3 USARTs, 5 UARTs;
    2 CAN interfaces (2.0B active);
    SDIO interface, FSMC interface, DVP;
    2 x I2C, 3 x SPI, 2 x IIS;
    80 I/O ports, can be mapped to 16 external interrupts;
    CRC calculation unit, 96-bit unique chip ID;
    Serial 2-wire debug interface;
    Packages: LQFP64M, LQFP100.

I have a CH32V203 that I'll probably add support for, along with the 307 or whatever else I can get access to easily.

Very cool, that's clearly a quite capable controller!

The AUD$20 is for the full dev board, the bare chip seems to be around US$3 [1]. I've never hand-soldered anything in LQFP-100, sounds exciting!

[1]: https://www.lcsc.com/products/Microcontroller-Units-MCUs-MPU...

That cool CH32V307VCT6 chip have 1GBPS ethernet MAC interface, yes 1 gigabit. For me is very interesting what is real benchmark numbers. anybody have any numbers?

I understand pico is cheap, versatile and overall convenient.

But is there anything (besides time) stopping you from implementing this on top of e.g. linux gpio?

The timing on the SWIO interface needs to be within a few hundred nanoseconds if you want decent bandwidth, but I suppose there's nothing stopping you from running it on a slower and less real-time GPIO pin. You'd just need to swap out the implementation of the PicoSWIO class, the rest would be identical.

The RaspberryPi has a SMI mode that should be able to handle 62 MhZ on a single pin usefully, did you investigate using that at all?

I'm not familiar with that interface, but I suspect it would have similar issues with timing tolerances as just bit-banging gpios.

It's a programmable, parallel data bus, like you'd get on an old school micro to access external rom and ram. It'll DMA to/from the Pi's RAM, and has programmable timings for read and write signaling, so it's not at all like bit-banging GPIOs. The only question is if it's usable for your debugger project, as it's not meant for that.

Pico is more than capable of handling timing within a few hundred nanoseconds with it's PIO (programmable IO) functionality.

You don't usually ever need to bitbang with RP2040.

Actually, on second thought I'm not sure that would work. If you had an interrupt fire in the middle of a bit and held the line low for more than 8 microseconds (I think, would have to check the spec) you'd reset the debug interface and have to start everything over.

>8 microseconds

Jesus christ. Nevermind what I said, then.

Hardware (HDL for cheap FPGA like iCE40) might be helpful.

A port to other microcontrollers should also be possible. Ideally you'd use a CH32V003 to assist in debugging/programming a second one.

But Linux is out of the question. That's way too tight even for linux-rt. Keeping scheduling latency in the two digit microseconds is hard enough, and about as good as it gets.

... it might still be possible with Linux, but only by dedicating a core to the purpose, and making it otherwise unavailable to Linux. I believe that's how PiStorm works.

In any event, how much effort any of these would involve is worth considering for determining whether or not it is worth doing, vs spending the time improving the rest of the project.

> Hardware (HDL for cheap FPGA like iCE40) might be helpful.

I'm a bit confused, isn't the pi pico the "hardware" in this instance? An FPGA seems like extreme overkill for this when the Pico's PIO peripheral exists (which is what the OP is using).

>An FPGA seems like extreme overkill for this when the Pico's PIO peripheral exists

Extreme overkill is good, particularly if it doesn't cost more money or use more power.

That specific family of FPGAs is optimized for low cost and low power.

Took a quick look at digikey:

RP2040 - 1x unit price = $0.70 iCE40 - 1x unit price = $2.50

I'm not sure if low power is necessarily a priority for a debug probe that's always hooked up to a computer, but the RP2040 seems competitive with power consumption. From what I can see in the datasheets, they're both on a 40nm process node.

I've never used the iCE40, is it easy to get a toolchain up and running for it? I haven't done any FPGA programming before but setting up the tooling always seemed more intimidating than using a standard C or Rust toolchain for a microcontroller.

I'd still opt for the RP2040 in this case.

RP2040 Datasheet - https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...

iCE40 Datasheet - https://www.latticesemi.com/~/media/LatticeSemi/Documents/Da...

Given the project needs more than just the MCU (or FPGA) chip itself, best to compare finished forms. The project OP posted uses a Pi Pico (aka ~$4) and a comparable form factor for an iCE40 is about $35-40ish.

Did the Pico steal your lunch money as a kid? Run over your dog? Otherwise why the extreme desire to use something ~10x more expensive and significantly higher power draw, for ZERO practical benefit? Don’t get me wrong, I love FPGAs and literally own dozens from $$ to $$$$ and have built many projects with them, but right tool for the job always should be considered.

Don't get me wrong. I have nothing against the pico, nor other cheap microcontroller devboards.

I own a bunch of microcontroller devboards including the pico, and a bunch of fpga devboards including many iCE40 variants.

Reply on news.ycombinator.com