add comment 93feac46f17a40fa41f543c56b5eafb2 on issue 2ff2ce2cae3914fbb8382372498abdd5

2ff2ce2cae3914fbb8382372498abdd5/comments/93feac46f17a40fa41f543c56b5eafb2/description

@@ -0,0 +1,21 @@
+had some pretty good progress tonight. got the board, soldered headers on, got it breadboarded, and got started trying to compile for the riscv core, and get the device flashed. 
+
+there's good HAL support, actually, which is awesome: 
+[ch32-hal](https://github.com/ch32-rs/ch32-hal)
+
+i was able to eventually get it compiling, however flashing was a different story. 
+
+apparently these chips don't have a 'standard' SWD implementation, and instead have some proprietary stuff from WCH which is annoying. 
+
+there was this project, which has been inactive for 2 years: 
+[picorvd](https://github.com/aappleby/picorvd) 
+
+it took a decent amount of work to get that project running - had to fix a bunch of broken dependencies, CMAKE version issues causing CMAKE to exit (protip: `export CMAKE_POLICY_VERSION_MINIMUM=3.5` from [stackoverflow](https://stackoverflow.com/questions/79534856/cannot-build-cmake-project-because-compatibility-with-cmake-3-5-has-been-remo). 
+
+once that was all fixed, and i had soldered headers on / flashed a pico - i then had to get the riscv64 version of GDB running, and talking to the pico. GDB did seem to have trouble with the probe sometimes, but i was able to (i think) flash a program to one of the boards.... and it bricked. 
+
+immediately i saw a bunch of activity on the SWD line, and the LED stopped blinking. 
+
+what concerned me is that the waveform did not go away after a long period of time. i did determine that the pico was the one driving the line (on the ch32v it's SWIO, so because there were debug prints in the code, i thought it might have been from that). 
+
+ultimately i think i'm going to just have to use the WCH Link(E?)... which is only $7 or so, but it does mean i'm going to have to wait for it...