Posts

Ethernet Swindle and gcc vs clang

Image
 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 that gcc has and clang does not "-msave-restore" Since the Riscv does not have stmia/ldmia style instruction, it must push and pop all registers one at a time when entering/exiting a function. That is consuming a lot of code space for short functions. The -msave-restore creates function to save/restore , all possible variants and call them instead of manually pushing/popping registers. Let's give it a try, baseline is clang + hw FPU: Clang + HW FPU    255 508   (+0kB) Clang + no FPU       257 632  (+2KB) Clang + FPU+LTO  232...
Post a Comment
Read more

SW breakpoint for the CH32V203 (and similar)

  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 page for the CH32V[2/3]xx - Read the page - Store the 16 bits where the breakpoint is - Replace those 16 bits by a "ebreak" opcode - Erase the page - Write the modified page When removing the breakpoint the same thing happens except we put back the original opcode. It is a bit slow, but usable. The main drawback is that it will speed up flash wearing a lot. The framework is in place, if and when need it will be easy to add such functions to other chips. The main difference with other flashing operations are : - we want to use the smaller size possible. Usually we aim a bit hig...
Post a Comment
Read more

Swindle : Preview 5 out

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

Swindle : RP2350 Coming soon (as host)

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

Swindle : Voltage translator merged

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

CH32V3, debug in ram with vscode continued

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

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