Going back to electronic after a 20 years break

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 "attach" You can only "launch" (this is specific to riscv) and that's the root of the problem. The init script looks like this :     {              "name" : "riscv GCC (pico)" , "type" : "gdb" , "request" : "launch" , "cwd" : "${workspaceRoot}" , "target" : "${workspaceRoot}/build/swindle_bootloader_ch32v3x_GCC_DEBUG.elf" , "gdbpath" : "${config:riscv_gdb}" , "breakAfterReset...

  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 debu...