Better support for CH32F103, a clone of STM32F103

[mean00]

Hi I have locally a patch to have flash writing working on the CH32F103 ( yet another STM32F103 clone ).

The "normal" BMP code fails when writing to flash. I think the flash on that clone is just too slow, the STM compatible code is probably failing with a timeout. It is REALLY slow in compatible mode, like 10 x slower than a regular STM32 chip.

The CH32 has a special mode (fast mode) which does work, is much faster (still slow), but is specific to CH32 chips.

I have it working, but i didn't find a way to properly autodetect such a clone (they have a designer id = arm, nothing special except Adiv version is 2 like the other clones)

What would be the proper way to ask nicely to the BMP to go to CH32 mode ?

[UweBonnes]

Undetectable devices are a PITA. I think at some point it is needed to be able to give the scan command a hint of the device to look for.

Otherwise , I wonder what happens. The ST flash stalls the bus while flashing is going on and the SWJ access should report wait. This should work even with sloooow flash. As always, I suggest to run with hosted to see if there is any error detected that is not yet or inappropriated reported to gdb. A pointer to english documents of the chip would help. On github, I only found chinese documents. Maybe some bit in some register that we can look at?

As a workaround, you can hack an adapted version of hosted and still use BMP/firmware the normal way.

[mean00]

I google translated the chinese datasheet, and it ended up not too bad. I can attach it if that helps I got something workish in BMP hosted mode, even though it's not 100% reliable (one 16 bytes writing error randomly).

The main issue is that the sample code from WCL is not doing the same thing as the datasheet says (which does not work), accessing undocumented flash registers (.....) with nice lines such as

• (__IO uint32_t)0x40022034 = (__IO uint32_t*)(Page_Address ^ 0x00000100);
  right in the middle of the code.

It may be possible to detect the chip because they put the USB pullup control bit right in the middle of the flash registers (....) so if i can toggle that bit, it probably means it's a CH32 chip.

[UweBonnes]

Argh, wild probing again.

What about creating a stm32f1clone_probe() that after checking the MCUID also checks for that toggle bit. stm32f1clone_probe() would only be called in cortexm.c
} else if (ap->ap_partno == 0x4c3) { / Cortex-M3 ROM / for clones. If the ch32 is not found, that function would switch to stm32f1_probe()

Did you see http://www.wch.cn/uploads/file/20210828/1630121707156657.pdf

At the moment, google translates times out on that.

[mean00]

For reference a link to what i did : https://github.com/mean00/blackmagic/tree/ch32 in case others want to have a look It is not optimized at all, and would need a good cleanup.

I've put most of the ch32 specific code in src/target/stm32f1_ch32.c that is included in stm32f1.c + the minimum change to support that. I think the probe function is ok but not 100% sure ( i only have gigadevice clones which have a proper designer id)

The bottom line is that it works fine in hosted mode, it is not too slow but it fails miserably when running natively on the probe (only writes the first 128 bytes chunk) I've asked WCH for additional documentation, maybe ...

The google translated doc is attached CH32F103DS1_en.pdf

Ps : the pdf you mentioned does also play with the undocumented flash register but in a different way compared to the sample code ^ 0x100 vs ^0x1000

[mean00]

i spent a bit more time on it and the end result is as follows : Using my test code :

• works fine in BMP hosted mode
• does not work well in normal BMP mode (the first chunk is not uploaded to the internal write buffer), so the first 16 bytes of each 128 bytes block is not written properly
• same code works fine when ran on the chip itself
• A normal flash code for stm32f1 works when ran on the chip itself, very slowly.
• OpenOCD seems to work albeit very slowly. From my understanding it copies a bit of code to the target and run it from there. So it's close to point 3.

That's really weird. Seems like a bus arbitration issue of some sort or something similar, where programming the flash from the "outside world" yields issue

[mean00]

Ok, found a hackish workaround : Poll the flash a bit till we see ffffff appearing meaning whatever operation in progress is done. PR coming.