Posts

CH32V3xx Faster development by doing everything ram

Image
  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 flash is really slow compared to other similar chips ( from STM or Gigadevice) Shadow Flash ? The chip has 'shadow flash' i think.  It is using slow flash ( or RRAM/MRAM)  and shadowing them with  RAM.  At reset , it copies the flash to ram and execute from there. That way you get low cost and fast execution time. The option bytes  allocates the physical ram between shadow flash area and ram area.  But the total cannot exceed the physical amount of ram, ~ 256+64 in my case. Debugging in bigger RAM Similarly to what was done with the RP2040, we can debug things in RAM and when it wor
Post a Comment
Read more

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"
Post a Comment
Read more

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
Post a Comment
Read more

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.
Post a Comment
Read more

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
Post a Comment
Read more

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
Post a Comment
Read more

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 :(
Post a Comment
Read more