Going back to electronic after a 20 years break

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

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

  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 a lnBMP + RP2040 zero in a 3D printed case soon.

  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 s i had in the spare box and solder it in place of the original one.  The screen is smaller than the original one but it's not really a problem. It works fine.

Lately, i updated lnDSO150 to v2.3, in particular its build system to be in sync with how i do things nowadays. The main goal is to easily switch between GCC and CLANG-17 (   arm or riscv ) The lnDSO150 has one variant (the FNIRSI one) with less flash ( only 64 kB), so i could use every flash gain possible Using clang + lto DID provide a nice size reduction (final size was ~ 50 kB for the fnirsi build) and at first it seemed to work alright. At first. Then, i realized that it made some underlying problem appear due its aggressive optimization. In other words, the bugs were there since day one, but hidden because the software was losing the race against the hardware every time. A couple of examples : - On the DSO150, some of the screen GPIO are reprogrammed as input to scan if  buttons have been pressed. If you flip the gpio too quickly, the button MAY keep the last state it was when used as output, causing random fake key pressed. Adding a couple of nops fixed the issue. - Sim...