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…
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…
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…
The DFU bootloader i wrote a while back for the swindle running on the CH32V303/CH32V307 was a quick job. It contained a cut down version of Esprit (the framework) with FreeRTOS and everything. It was about 14kB big. Since i'm playing with antigravity/gemini, it was a good sample task to run it. (On the antigravity front : it does a good job. But you really want to give small tasks, with clear…
I was not really happy with the CH32V307 Ethernet Version. It is a all-included & cheap version. But it's only 10 Mbps and there is not enough flash/sram to comfortably host swindle. The ESP32S3 wifi based version is sort of working, but the performances are not that great and i had to hack a lot to make rust + esp + cmake based project playing nice together. So here comes the new challenger :…
A quick port to support the ESP32S3 mini over Wifi. The pic below is a ESP32S3 debugging a bluepill board (still over wifi) Github page
New year version Preview 6 https://github.com/mean00/swindle/releases Ethernet version for the CH32V307 eval board RTT & serial fixes Updated blackmagic engine Breakpoints in Flash for CH32V1/2
There will be soon a new flavor of the swindle : The ethernet swindle It's starting to work nicely, utltimately the goal is to use the CH32V208 that is available for ~ 4$ on aliexpress. It's basically a CH32V307 without HS usb and without fpu, same flash, same ram (more on that later). LWIP is pretty big and i'm running short on both flash & ram. While looking into it, i discovered a nice option…
The WCH doc clearly states the QingKev4 b does not have hardware breakpoints. We saw that a bit earlier. The CH32V203 among others is a QingKeV4 b . I've added support for flash software breakpoint for the CH32V[2/3]xx to swindle. It is still a bit experimental. When such software breakpoints are used, under the hood the following happens : - Identify the page where the breakpoint is ( 256 bytes…
After a long time, Swindle preview 5 is out, small changelog - Updated to latest blackmagic engine - Preliminary support for RP2350 (host and target) - Support for voltage translators - RTT support (with auto setup) - Better cortex register support (including trustzone ones) - Overall better stability, it should freeze much less often - and of course continued support for CH32V30x (host and…
Now that the prices are coming down, making your own debug probe with a RP2350 is almost there. Don't expect big changes, the RP2040 is already powerful enough. Nb: since the blackmagic already supports the RP2350, it is already included
The latest bunch of change was merged. The main change is the addition of a voltage translator to allow operation with a lower voltage chip. There is a jumper to select between native (3.3v) and translated (1.2, 1.5, ..) voltage Example with a RP2040 + Carrier board with voltage translators (They are a pain to solder btw, i put them too close to each others). Only CH32V3xx and RP2040 for now !
Summary of previous episodes (CH32v3): 1- Reallocate shadow ram to have 128k of RAM 2- In flash, put a basic harmless loop 3- Tweak the linker script to put everything in ram 4- Load the code (to ram), change the PC to the code in ram 5- You now upload much faster with infinite software breakpoints Vscode You can use the cortexm extension with riscv, it works fine with one caveat : you cannot…
Debugging the CH32V3xx (and V2xx) The CH32V3xx chips are rather good, they are pretty fast, cheap with tons of peripherals. Swindle supports the CH32V3xx chips (CH32V2XX as well but they are less interesting imho). Debugging with them is not so great : - They completely lack watchpoint (some revisions of WCH riscv cores do have them, but not the CH32V3x it seems) - Only 4 breakpoints - Writing to…
A small release of swindle, a blackmagic derivative with rust in it : Changelog (short): - Better CH32v3xx support (host and target) - Rewrote ADiv logic so that we can ... - Use RP2040 PIO hardware to drive SWD - Update to latest blackmagic and still the M ain features : - Run on GD32F303, CH32V303, RP2040 - Support ARM devices and WCH riscv devices (CH32V2xx and CH32V3xx) - Soft breakpoint to…
The main problem when debugging the code in ram is that the CPU will have started to execute whatever is in flash before you catch it, including potentially clearing the ram. As a result , the setup has to be done in 2 steps : - Have a "null" program in flash that does nothing -Tweak a little bit the vscode debug startup sequence Loop in flash The idea here is to modify the very first instruction…
A couple of months back i bought some CH32V203 on ebay. Why ? They were cheap, they are pin to pin compatible with STM32F103Cxxxx, i can put them on bluepill board . They are fast riscv. Why not. NB: by mistake i bought the ones with 64kB of flash :( But there is a BIG showstopper, there seems to be no hw breakpoints, only sw breakpoints. If you have a lot of ram (like the RP2040) you can put the…
In order to avoid confusion , i renamed lnBMP to swindle (swindle has SWD in it) It can run on : GD32F303 CH32V303/5/7 (just need enough flash /ram) RP2040 (normal or zero) and it can debug all the usual blackmagic targets + CH32V2XX/CH32V3XX. I dropped support for the bluepill / STM32F103 because it has not enough ram/flash and the CH32/GD32/RP are so cheap it is not even worth the time. The next…
The RP2040 has a lot of RAM (264 kB) that is faster than the external flash and easier to use. It makes sense to put smallish code there to speed up the build/load/debug cycles until it works. Additionally, putting code in ram is a good way to speed up execution and/or deal with flash erase/writing. and.... it does not work well, the breakpoints are not triggering. How come ? The flash starts at…
It is painful, but it is beginning to work : On the picture a RP2040-pico zero running lnBMP and happily debugging a ch32v307 Riscv chip (of course it can still debug Arm chips) Perigoso did a lot of work there, only the communication protocol /implementation was missing. It is still a bit slow though :(
Edit: There is a much simpler way. Press the Key Button will connecting the USB-C , it will switch between ARM & RISCV I recently bought the WeAct WCHLINK-W, a small dap style debugger (both USB & BT) At first it is configured in Arm/SWD mode and is being listed as 1a86:8012 QinHeng Electronics by lsusb. On linux, the simpler way to switch it to RiscV mode is to download mountriver community Then…
lnBMP : Lots of little issues tackled : - Preliminary FreeRTOS awareness through "mon fos M0|M3|M33' - Uart <->USB through DMA, that one was a pain - Configuration change to map the supported boards depending on the amount of RAM we have. But finally, here it is : lnBMP running on a RP2040 in a itsy bitsy case, and it works !
In the eternal goal of having the smaller debugger possible, i ended up porting the strict minimum of lnBMP on top of the RP2040 chip. Tinyusb is available so that part was not problem. Clang + Rust, no problem either. The pico sdk is providing the basics , already CMake based. Using DMA+Uart was a bit more complicated but not that much at the end of the day. And ...It works !, expect nice pics of…
This morning i realized the screen of my soldering iron was broken. I like that soldering iron, it is similar to that one with a STC chip and the main power supply included. I looked on the net and found this post My T12 control board is slightly different; it is not just connecting the VCC/VDD/SCL/SDA but the whole 30 pins ribbon. I removed the whole lcd+ribbon from one of those cheap LCD screen…