Swindle : Downloading code to the CH32VXX faster

 Now that the new bootloader shown that it can be fast to write to the CH32v3xx flash, time to revisit the swindle way of loading code.

(Gemini was really helpful again. But as a smart assistant, no vibe coding here).

Starting point:

So we started around average speed of 3kB/S (including erase, download and write)

Optim 1: use bigger blocks

Before, we were configuring the block size/erase size to be 256 bytes (same as the small hardware pages).

Reconfiguring the description to be 4kB gave a small speed bump => 5 kB

(internally it will call 256 bytes multiple times, it just reduces the overhead).


Optim 2: Faster writing to RAM

The dominant slowdown is the amount of time needed to write to the CH32V3xx ram (then we call the flashstub to actually write it, that's pretty fast).

Just the writing caps the overall speed to 9 kB/s , without even erasing or writing.

So the optimisation is to use a fast_write_ram function there that is using abstract commands with auto exec to pipeline data write to ram. It's about 4x timer faster

(Nb: it works here because the debug link is so slow there is no need to wait for the write command to be done to switch to the next one)


=> Overall speed is now 8kB/S Better but still not great


Optim 3: Varying block size


That one is a little bit more intrusive. Declare (optionnaly) a list of erase block sizes, and erase using the biggest possible block size (taking into account alignment). For the CH32v3xx we can now use the 32k Erase like with the DFU bootloader.

==> Overall Speed is now 25 kB/S

Wait a minute

It's actually more nuanced than that. The end result is actually a mix of two behaviours : 
- when it can use 32kB erase, more than 25 kB/s
- when it cannot, much less like 8kB/s

so if you write large blocks (like 200kB), the overall speed is closer to 25 kB/s
but when you write smaller firmware, where there is not a lot of full 32kB blocks it is more in the 8 kBs/s range.


Nonethless, it is now bearable, while before it was in the 1mn range to flash the whole swindle firmware. Now it's more in the 15sec range.

Comments

Post a Comment

Popular posts from this blog

G600 Microscope Battery charging mod

Image
While thinking about replacing the mini usb connector to a micro one on my G600 microscope , i've  seen that   post  from Syonyk. Damn ! No real battery charging, straight to 5v. Warning : This is not an accurate analysis, it may contain errors or missing /misunderstood parts. Let's have a look. The partially reverse engineered/ contains error schematic /picture is as follows : The equivalent schematic is ( incomplete/may contain error ) : So indeed, VBUS (5v) is connected directly to VBAT through just a schottky (K14) and R12. On the other hand, the BMS circuit is tuned very low and will stop the charge at exactly 4.2 v. My battery is still healthy and only slightly puffy :) Let's use a real charging circuit and remove component so that VBUS is completely isolated from VBAT. Remove K14, the P-Mosfet (Q1) and R54 so that they are really isolated and there is no  resistor between VBUS and ground (R54). I also removed a very small ...
Read more

INA3221, weird wiring

Image
Continuing my "smart" battery charger, i've finally received the INA3221 module. It is the purple one you can find on ebay for ~ 5 bucks I soldered a couple of pins to be able to connect it so that i could test it and something immediately caught my attention. It is supposed to be a high side current/voltage sensor, typically in a setup like that : So you can measure the voltage supplied to the load, and the current going through it. Now, let's have a look at the module, look at the top of the following pic, where the sense connectors are. CH3/GND/CH2/GND/CH1/GND ? Wait ? What ? Yes, all the IN- pins are connected to ground, so it is a bottom current only sensor. Additionally, the - side of the shunts are ALSO connected to the ground, no only the connectors. The actual layout is like that : That raises two problems :  The voltage is meaningless as we are only measuring Current x ShuntValue, not the supply volt...
Read more

Component tester with STM32 : Part 1 ADC, Resistor

Image
I was always  fascinated by the so call "transistor testers" that identify and report pin out, features of pretty much whatever you throw at it. They are based on Atmel 328p chip, the same as arduino nano. So why not do the same thing with a STM32/Bluepill ? The STM32 is faster, has a better ADC accuracy, more memory, can do float etc... and is not more expensive. Warning : I'm doing this for fun & to learn, it might contain error & plain misunderstanding So, i watched a couple of video on the general principle on how they work. This is not a "port" but a rewrite from ~ scratch. When something is weird, i check what the original one does for comparison. Measuring resistance So first thing first :  Resistance & Capacitance. These 2 will unlock the other ones. So how do we measure resistance ? What we do is a resistor divider with a know resistance value: Measure = Vcc*(RtoTest/(RtoTest+Rknown)) As far as the ADC goes, it means ADC=...
Read more