Going back to electronic after a 20 years break

   Link  to a snapshot of the CH32V003 aware version of swindle for the RP2040 Gunzip the uf2 and do as usual to flash the rp2040 with the uf2. YOU ABSOLUTELY NEED A 1KOhm RESISTOR BETWEEN IO and 3.3v! Pinout : -CH32 IO pin : GPIO13 of RP2040 (+1K pullup to 3.3v!) -CH232 reset : GPIO10 of RP2040 (optional) - Ground! To use you need to setup gdb the following way (~ same thing with vscode) target extended-remote /dev/ttyACM0  (name of the CDC device) set remotetimeout 500000 monitor sdi_scan set mem inaccessible-by-default off set confirm off attach 1 load compare-sections If you see  " Detected CH32V003 chip with 16 k flash, 2 k ram ", it works!. Nb: It does not work very well with CH32V006, looks okay for CH32V003 NB2: The same firmware also supports CH32V2x|V3x/RP2040/STM32/.....

 It has been a long time this has been on my todo list. I made the sw breakpoint framework a while back because i knew i would need it for that. Same for the RISCV flashstub framework. So with the assistance of deepseek/gemini to speed things up : Load and debug CH32V003 chip And it works, with breakpoints and everything : It is still early and a bit slow. Important :  - You ABSOLUTELY need a 1kB pullup on the IO pin (same pin used for SWDIO or RVIO). That should not be a problem when debugging CH32V23 or Arm chip. - Only RP2040 host for the moment

 Now that the new esp idf and associated rust binding (esp-idf, esp-svc,..) are out,  time to update esp32-swindle with S3, C3 and C6 support You'll need to use the Espressif BLE provisioning tool to transfer the wifi credentials. (and use the console to get the IP address at least once) NB: The zero boards usually have pretty bad WIFI connection An ultra cheap ESP32C3 debugging a STM32 bluepill over wifi :  Github link

 This is a small summary of why accessing memory when debugging a riscv cpu is complicated. It is work in progress, the current code is available on swindle's github. Introduction As usual, as it is RISCV, a lot is optional with important details left to implementation So let's see what is possible (definition from Gemini): Recommended : Program Buffer Execution (ProgBuf): Memory is accessed by halting the CPU and executing standard load or store instructions placed into a dedicated buffer. This uses the core's native pipeline, meaning all MMU translations, Physical Memory Protection (PMP), and cache hierarchy rules apply automatically. Optional: System Bus Access (SysBus): The Debug Module acts as an independent master directly on the system interconnect, bypassing the CPU entirely. This allows reading or writing physical memory while the core is actively running, though it does not go through the CPU's MMU or local L1/L2 caches. (NB this is more or less what ARM doe...

 That's a topic,  i've been playing with recently. The CH32V3xx and CH32V2xx RISC-V families have a internal bootloader that is able to flash software over USB or UART. No need for swindle, wch-link, ... (you'll need them to debug though). You can use that to flash the CH32V3xx DFU bootloader for example. There is a very nice project   CHISP-Flasher  that can flash elf/bin/.. over USB and available both as CLI or with a Qt6 GUI. Warning: not only do you need to have the BOOT0 pin High at boot, but you ALSO need to have the PB2  pin grounded at boot.

  Faster bootloaders for GD32 & CH32 (you can keep using the old ones if you have them already): - Fix(?) flashing issue on RP2040 - Faster CH32V2/3 flashing - Better FreeRTOS support for ARM, Riscv & WCH - Experimental support for RP2040+W5500 (Ethernet swindle) - Updated Blackmagic engine -  General stability fixes Download link