标签：#riscv

I wanted to see if an ESP32-S3 could be used as a programmer for the WCH CH32V003 instead of using a dedicated WCH-Link. The final setup is: PC → ESP32-S3 → SWIO → CH32V003 The ESP32-S3 handles the timing-sensitive SWIO communication and the CH32 debug/DMI interface. On top of that I implemented target detection, memory access, flash unlock, page erase, programming, read-back verification and reset/run. Hardware ESP32-S3 N8R2 CH32V003A4M6 (SOP-16) 4.7kΩ–10kΩ SWIO pull-up CP6208 motor driver Small DC motor 3.7V Li-ion battery Breadboard Important connections: ESP32-S3 GPIO10 → CH32V003 SWIO ESP32-S3 3.3V → CH32V003 VDD Common GND External pull-up on SWIO CH32V003 PC4 → CP6208 control input The software stack The programmer is split into several layers: text PC │ │ Python host tool ▼ ESP32-S3 │ │ SWIO ▼ WCH DMI │ ▼ CH32V003 debug module │ ▼ Abstract commands / program buffer │ ▼ Flash controller The ESP32-S3 is doing the SWIO timing directly rather than relying on a separate programmer IC. I used existing open-source CH32/SWIO implementations as references, particularly CNLohr's CH32V003 work and BlueSyncLine's SWIO implementation. Getting SWIO working The first versions did not work. One of the early failures was: SWIO sync: FAILED DMCFGR = 0xFFFFFFFF I had to work through the SWIO startup sequence, timing, receive behavior and physical wiring before getting reliable target responses. Once it was working, the programmer reported: SWIO sync: OK DMI communication: OK Target detect: OK CH32 ID = 0x0713BB91 Target memory read: OK That gave me a stable base for the flash implementation. Flash programming I then added the flash controller operations: flash unlock 64-byte page erase fast page programming read-back verification target reset/run One useful milestone was observing the flash lock transition: FLASH_CTLR before unlock: 0x00008080 FLASH_CTLR after unlock: 0x00000200 After that I tested programming and verification using deterministic data. The programmer was able