Posts

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

lnBMP : rp2040, Not forgotten

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

lnBMP + RP2040 ?

 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.

Reparing the screen of a Quicko T12 soldering iron

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

clang-17, lto and aggressive optimisations

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. - Similarly, t

lnBMP + CH32V303!

Image
 Finally got the PCB (that was my first one) As expected a couple of mistakes (selected footprints too small etc..) but it works! Since the CH32V303 is running at 140 Mhz, it is faster than the bluepill based one. For reference, i did the same PCB for a GD32F303, and it was more complicated. The ch32v303 version is much simpler, no need for extra glue. The chip, a 8mhz crystal, couple of resistors and caps and that's it. I've also ran into a false problem. The normal BMP  just reboots when it asserts, so you dont see that happening. The lnBMP halts when it asserts, took me a bit of time to realize that was not due to a problem i introduced.