Going back to electronic after a 20 years break

 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

 Now that the new bootloader has shown that it can be fast to write to the CH32v3xx flash, time to revisit the swindle way of loading code. (Gemini was really helpful again. But as a smart assistant, no vibe coding here). Starting point: So we started around average speed of 3kB/S (including erase, download and write) Optim 1: use bigger blocks Before, we were configuring the block size/erase size to be 256 bytes (same as the small hardware pages). Reconfiguring the description to be 4kB gave a small speed bump => 5 kB (internally it will call 256 bytes multiple times, it just reduces the overhead). Optim 2: Faster writing to RAM The dominant slowdown is the amount of time needed to write to the CH32V3xx ram (then we call the flashstub to actually write it, that's pretty fast). Just the writing caps the overall speed to 9 kB/s , without even erasing or writing. So the optimisation is to use a fast_write_ram function there that is using abstract commands with auto exec to pipelin...