Posts

swindle (lnBMP) v0.3

 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 debug code in ram (Arm only for now) - Built in FreeRTOS support through  "mon fos M0|M4|RV"

Setting up vscode+bmp/vscode to debug code in ram (RP2040)

 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 and replace it with a endless loop. When you use lnArduino that means changing  mcus/arm_rp2040/sdk_copy/crt0.S and replacing the first instruction by       b _entry_point That way, after reset, it will harmelessly loop in the flash. Cortex-debug setup {   "version": "0.2.0", "configurations": [ { "name": "RAM- pico-load", "cwd": "${workspaceFolder}", "svdFile" : "${workspaceRoot}/.vscode/rp2040.svd", "executable": "build/st7789.elf", "gdbPath" : "${co

CH32V203C8xx : no breakpoint ? :(

 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 code in ram until it works fine and then put it in flash. That's not the case here. Having the debugger read/modify/write all the time to but sw breakpoint in flash is really a pain. In theory, the "flash" of the CH32 is actually flash copied to ram, so if there was a way to use the fake flash ram to put SW breakpoint in it, we would be good. For reference, the CH32V303 has only 4 breakpoints, and no watchpoint (i.e. triggers with the right capabilities) which is already a bit of a pain in the neck. I'll put those aside for the moment.

lnBMP => Swindle

Image
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 item on my todo list is to update the blackmagic part and to use the PIO controller inside the RP2040 to do SWD / RVSW (Arm/CH32) Example: a itsy bitsy RP2040 zero debugging a CH32V30X based swindle board

rp2040 + BMP : Debugging code in RAM ?

  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 address 0x1000 0000, the RAM starts at 0x2000 0000 BUT if you look at the cortex M0 breakpoint unit it can only put so called hw breakpoint between 0 and 0x1FFF FFFF, so it cannot put hw breakpoint in the RP2040 ram. As a result we need to use software breakpoint. It means replacing the opcode of the line you want to break on by a "brk #0" and putting back the old opcode when you stop.  Gdb does that through using Z0 for sw breakpoint and Z1 for hw breakpoint. Let's add that to swindle. There is a basic/naive implementation of ARM sw breakpoint on the dev branch of swindle, now

lnBMP : CH32V3xx support

Image
 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 :(

CH32Vxx : WCH_LINKW in riscv mode

Image
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 go to Flash->Configuration Click Query on the "Target Mode" line. It should be detected as WCH DapLink Switch it to "WCH Link RV", click apply , wait 2 seconds and done! The id of the device has changed and now lsusb should report 1a86:8010 QinHeng Electronics