CS32F103C8T6… A new clone?

Found on Aliexpress this CS32F103C8T6.

I haven’t found any datasheet of it…

Some others “sighting” on EEVblog and here…

On the EEVblog page they say: “It isn’t a clone of the STM32 silicon since it has some differences like this SW-DP DPIDR change.“…

Interesting

Here is a link to a BluePill on AliExpress using one of these

https://www.aliexpress.com/item/Free-Sh … 08361.html

Strangely its showing on AliExpress that there have been over 3500 of these sold, but I suspect thats probably not the case, and that most of them were STM32 versions and only the more recent ones use the CS32F103C8T6

Also. When I search for “CS32F103C8T6” I get loads of hits for other vendors selling BluePills using this chip.

I guess I should check all my BluePill’s to see if I already have one of these but have not noticed, as I rarely look at the STM32 its self when I get a batch of BP’s

hmm, interesting, but also a bit annoying if they’re not 100% compatible >_<

May be that the only difference is the ID… but I haven’t one to test…

I may order 1 or 2 to test, but I’ll have to wait ages for them to arrive, as I don’t want to pay twice the price of the board for quicker shipping

I bit the bullet and ordered 2 of these, and paid for ePacket shipping so they should be here in 2 or 3 weeks

is there a reason they’re moving away from the original, does anyone know of a shortage, or the prices going up or…

locally produced so a substantial profit margin increment for them.

Now, I need a datasheet to find out the differences, if it is like the GD32 with a wired-bond SPI Flash chip in the package or not.

Found the datasheet (with the help of an other forum) here.

But it is in Chinese only…

Given the number of pages it seems the complete datasheet.

Thanks for finding the data sheet

I know some people on the eevblog forum are investigating it, so I will repost the link on there as well

I tried to get google translate to translate it, but it’s too big. So I will see if I can split it into smaller parts and try again.

It looks like it is very close to the Chinese version of STM32F10xxx RM0008, except that sections not relevant to the STM32F103 (USB OTG, Ethernet, etc.) have been removed.

Let’s hope it is 100% compatible, that they installed the right USB 1k5 pull-up and that they burned the Arduino bootloader

Hopefully I should get the board in about 2 weeks, as ePacket doesn’t usually take too long.

The supplier claims to have posted it yesterday, but the tracking code is not active yet.

One thing I noticed in the datasheet was this in the SRAM section (translated using google translate)

CS32F103C8 Built in 64K Byte static SRAM . It can be in bytes, halfwords (16 Bit ) Full word (32 Bit ) access. SRAM The starting address is 0x2000 0000 .

I don’t really understand this, because the Chinese datasheet for the STM32 that @sqonk linked to, also has that value in it, but perhaps the STM32 datasheet was for all STM32F103 versions and some of them have 64k RAM.

So its hard to know whether the CS32F103C8 has 64k RAM or whether its just that they copied the datasheet for all F103 versions for their C8 version and didnt bother to change that value

[RogerClark – Wed Jan 23, 2019 9:27 pm] –
EDIT..

I think perhaps the term SRAM means flash,

No, no, the Flash is detailed in a following section “2.3.3 嵌入式闪存” (“2.3.3 Embedded Flash”) : it looks like it goes up to 512K, but table 2 only shows 128 x 1K pages like the STM32F103.

[RogerClark – Wed Jan 23, 2019 9:27 pm] –
I don’t really understand this, because the Chinese datasheet for the STM32 that @sqonk linked to, also has that value in it, but perhaps the STM32 datasheet was for all STM32F103 versions and some of them have 64k RAM.

So its hard to know whether the CS32F103C8 has 64k RAM or whether its just that they copied the datasheet for all F103 versions for their C8 version and didnt bother to change that value

I think this is the case: they removed the table for high-density devices, but did not get this one.

Really strange though, such a similar edited datasheet would require to get access to the original Word document, it would be very difficult to obtain this level of fidelity by starting from a PDF.

Could it be that STM sub-licenced the good’ol STM32F103 for the Chinese market?

I’ve tried to convert the data sheet into English, via a rather convoluted route, which lost some of the formatting.

You can download the PDF from my google drive

https://drive.google.com/open?id=1dsH1Q … BliQag9xj0

I’ll post it to the thread on eevblog as well, because someone on there already has some BP’s with this chip on it, and is going to do some testing

there is some example code i can found on there website
http://www.ckscup.com/upload/%E4%B8%AD% … %BA%8F.rar

and also another PDF sheet, from page 6 it says 20k sram
http://www.ckscup.com/upload/CKS%20CS32 … %86%8C.pdf

Most of the code examples seem to be from ST themselves, but its pre-HAL, examples which are around 8 years old.

tsck, tsck, tsck..

I’ve just discovered that a blue pill board I got a couple of months ago is one of these. (I’d never actually tried it until today!)

It was totally unresponsive to my attempts to upload over serial, but I’ve managed to install the bootloader using another blue pill board running as an st-link.
With the bootloader installed, a basic blink program will happily upload and run.

That’s enough for me for today, but if you have any tests you’d like me to run to try and characterize this thing a bit more I’m happy to help (as time/energy allows!)

[deathterrapin – Tue Jan 29, 2019 9:49 pm] –
I’ve just discovered that a blue pill board I got a couple of months ago is one of these. (I’d never actually tried it until today!)

It was totally unresponsive to my attempts to upload over serial, but I’ve managed to install the bootloader using another blue pill board running as an st-link.
With the bootloader installed, a basic blink program will happily upload and run.

That’s enough for me for today, but if you have any tests you’d like me to run to try and characterize this thing a bit more I’m happy to help (as time/energy allows!)

Interesting. Do you mean the internal Serial Bootloader (which is activated by pulling Boot0 high) does not work ?

Also, some people reported having problems uploading anything via ST-Link because the device ID is different, but perhaps they were using a different kind of programming hardware

BTW.
How long ago did you order the board ?

I’ve had a quick look at some of my BP’s and I’ve not found one that contained this chip.

Yeah, the serial bootloader wouldn’t work for me, I’m pretty sure I wasn’t doing anything totally stupid as I used exactly the same method to put the st-link firmware on the other board.

I ordered the board on the 27th of November, from here: https://www.aliexpress.com/item/Free-Sh … 036ccc9531

I ordered from the same store. They are possibly the only ones selling this version of the blue pill

Done a little more testing.
It apparently only has 64k of flash, I couldn’t get a larger program to flash correctly.
Also, despite it being a slightly revised board layout, they haven’t fixed the USB resistor.

Ok..

Sounds like they are going after the market for a completely compatible STM32 rather than what GD did, and add new features.

It would have been nice to have more RAM and also to have 128k or more, but my guess would be that they decided that diverging from the exact spec of the F103C8 was too much of a risk

I found this page with all resources on the CS32F103C8T6 in one place, including:

• Datahseet
• Reference Manual
• Eval Board User’s Guide NEW!
• Eval Board Schematics NEW!
• BSP
• LCD and Touch Panel driver NEW!
• Keil plugin NEW!

http://www.ckscup.com/material.aspx

Direct link to evaluation board schematic

http://www.ckscup.com/upload/yuanlitu.pdf

I’ve no idea why they decided they needed to use a transistor in the circuit for the USB D+ pullup.
Seems a complete waste of a transistor, when the could have simply directly use a jump link to determine whether to pull up USB D+

Leaving the base of the transistor floating if the link is not inserted seems an odd design decision.

Yeah, and whem I remember the discussion we had here regarding the precautions to take on the Bluepill F4 SDCard

Here the SDCard is mounted with a simple 100n cap, and all signals go through jumpers Same for USB. And of course, AVCC directly tied to VCC. I just hope that the 1k5 USB pull-up has the right value on the board.

I’m not sure if anyone makes the evaluation board for this chip using that schematic

I think whoever makes the BluePill simply changed the BOM from STM32F103C8 to CS32F103C8

i took the bait and ordered 2 as well
my guess is that there are limits to that ‘compability’ and as some mentioned serial uploads didn’t seem to work

I am still waiting for mine to arrive.

I think Lunar New Year is delaying deliveries from China

I’ve got about 7 items ‘in transit’ :/

[BennehBoy – Tue Feb 05, 2019 10:58 pm] –
I’ve got about 7 items ‘in transit’ :/

Do you mean 7 of these boards or 7 different items ?

Mine arrived today

STLink reports the same ID code 0x410 but reports 128k instead of 64k

i.e

STM32 STLink connection data
12:41:19 : ST-LINK SN :
12:41:19 : V2J27S6
12:41:19 : Connected via SWD.
12:41:19 : SWD Frequency = 4,0 MHz.
12:41:19 : Connection mode : Connect Under Reset.
12:41:19 : Debug in Low Power mode enabled.
12:41:19 : Device ID:0x410
12:41:19 : Device flash Size : 64KBytes
12:41:19 : Device family :STM32F10xx Medium-density

I’ve tied to upload via UART Serial, but so far I’ve not been able to make it work.

I’ve tried using STM’s own Windows application, and tried swapping PA9 and PA10 in case my USB to serial was miss-labelled.

Just in case its an issue with my USB to serial adaptor, I’ll need to find a normal STM32 BluePill board which I’m not already using, and test it on that one.

Also.

I’ve noticed that these PCB’s are slightly different from the STM32 BP PCBs

The USB socket is physically different as it only has 2 restraining pin on each side, and the reset button is smaller, and only has 2 SMD pads rather than 4.
This leaves room on this PCB for the Boot0 and Boot1 pins to be labelled, and there is some text which reads “STM32” (followed by what looks like a degree symbol, though it could be a very small “o”)

The underside of the PCB looks similar to my other PB’s but there could be minor differences

What about the USB pull-up?

I just measured PA12 to 3.3V and its reading exactly 10k on my multimeter, so it looks like they’ve not fixed that issue on this board.

I’m constantly amazed at the low level of understanding that these engineers have, and they obviously don’t use the boards themselves, otherwise they’d know about the problems, and the USB specification.

The board works OK on my PC, but most BP’s even with 10k resistors work OK for me.

I may contact the supplier and tell them, about the mistake, but I suspect they’ll ignore me.

I’ve sent a contact message to WAVGAT store on AliEpress, who seem to be the only vendors of this board, but I don’t know if they will bother to take my advice.

I guess RobotDyn changed their design, so there is a small glimmer of hope

RobotDyn is a manufacturer, I am not sure that Wavgat is.

For the Bluepill, it looks like the original design was done by Earth-gnd.com vcc-gnd.com, then copied and “optimized” to use extremely common components. Unfortunately, a 1k5 resistor is a little too exotic, and they replaced it with a very common 10k, fount it is still somehow working. Don’t ask where they get the STM32 chips (probably refurbished, if not illegal copies), and using crystals with tvery loose specs.

Probably this copy was in turn copied, but most of them don’t even understand the problem and/or the USB specs.

And most of the Aliexpress stores are just individuals running their business from a 10m2 flat in HK, provisioninng items from Mainland when they get an order, so they don’t even understand what they sell.

Yep.

I’ve No idea whether WAVGAT actually make them, or just resell them.

I just retested the internal Serial bootloader and it seems to work OK.

I’m not sure why it wasn’t working when I tried it earlier today.

Unfortunately I don’t have any projects where I can simply plug in a BP to test other things, because the projects I made last year with custom PCB’s use the Maple Mini.

So I’d need to use a breadboard to wire up some test configurations.

[RogerClark – Tue Feb 05, 2019 11:05 pm] –

[BennehBoy – Tue Feb 05, 2019 10:58 pm] –
I’ve got about 7 items ‘in transit’ :/

Do you mean 7 of these boards or 7 different items ?

7 different items. I’ve steered clear of ordering one of these.

OK.

I just checked, and I ordered these on 22nd Jan via ePacket, and they arrived today.
So thats 12 days, and included part of their Lunar New Year

Not too bad, but I did pay several dollars extra for ePacket

Surfing on Aliexpress I found some bluepills but the photo has the chip name erased with black
examples
https://www.aliexpress.com/item/STM32F1 … 48071.html
description is empty
https://www.aliexpress.com/item/1-pices … 12819.html
Description says that there is an STM32F103C8T6 but a customer says that it’s a clone.
This one
https://www.aliexpress.com/item/STM32F1 … 63343.html seems a black pill, seems to be made from the same people (ZucZug) but photos shows the STM32 chip I didn’t find any feedback that says that this chip is a clone and one customer was able to flash Roger’s bootloader.

Looks like the same board

The reset button is thinner and rectangular rather than square, it looks cheaper than the button on the STM32 BPs

The bootloader seems to work fine with these chips, but I have not tested any peripherals

They seem to have 128k flash, so in some respects they are better than the STM32F103C6 rebadged to make them look like a C8

I have not done any speed testing, to see if they are like the GD32 and use shadow RAM, but they probably don’t

It looks like the CS32 are really STM32 silicon clones this time, unlike the GD32. I wonder if they are authorized copies or not.

i noted that the datasheet for cs32f103c8t6 mentioned as either 64k flash or 128k flash
http://www.ckscup.com/upload/CKS%20CS32 … %86%8C.pdf
(too large for google translate can’t post the translate link)
it is rather interesting that they provided 128k for the c8 variant, i’d guess as it become an ‘expected feature’
they provided that flash bump so as not to disappoint fans
i’d guess it is necessary to flash something above 64k to confirm if after all there is flash sitting there

btw it seem quite possible that these are pirated, but it’d be a little strange as i tend to think the masks and frontend processes are not likely in china but perhaps there are plants in some other countries in which they are pirated
reverse engineering is quite possible but that effort would likely be huge and would possibly cost lots to do just that.
it would more likely to be a reverse engineered product if there are some additional features that is hardware based
but for now it doesn’t seem so other than an ‘unexpected idcode’ while flashing as mentioned in eevblog forum
https://www.eevblog.com/forum/beginners … ill-clone/
the thing is is that ‘idcode’ hardware or software, if it is software or firmware then even that ‘idcode’ glitch would not tell if after all the chip is reverse engineered or simply that the masks (and processes) is pirated

I only tested one of my boards, but its a C8 and definitely has 128k, as I’ve written and verified a random binary file to the board.

PS. Initially I made a 128k data file with 0xDEAD 0XBEEF repeated throughout.
But I realised that the read back verification would not spot a problem if the 64k was mirrored to 128k, so I used a file filled from /dev/random and that also verified

So I’m pretty confident the chips I have are 128k (but still only 20k RAM )

This is the same in STM datasheet that refernces both the STM32F103C8 and STM32F103CB versions, nothing to do with fans

In the STM32F103, the Flash size can be determined at run time using the F_SIZE register (address 0x1FFFF7E0 on the STM32F103C8T6), maybe this is also the case for this chip?

Producing a set of masks for a silicon chip is extremely expensive so I suspect that STM is only using a single set for a given family, withe maximum Flash memory size, then tune the chip to the final marketing version by blowing (or not) fuses during production.

There are silicon die manufacturing sites in China, and it may be possible that the government imposes local production to access their local market. Maybe the CS32 is such an offspring?

What is amazing is the similtude between the CS32 datasheet and the STM32 datasheet and RM in Chinese from STM: the contents and even formatting is so similar that it is almost impossible that this can be obtined without the source doxuments.

Unlike the GD32 which is clearly a different chip for which GigaDevice is’using its experience in Flash memories by bonding a separate chip, they just bought a licence for the CM3 core from ARM as well as reused the same silicon IPs for almost all peripherals, and mapped them to the same memory location so it will be easier to test…

my guess is that st (or someone) would probably remove the housing and compare the die photos, if it turns out the die photos are identical as well. then it is pretty much pirated.
if the die photos are different in some significant ways, it would then be likely that it is reverse engineered
if it is reversed engineered, it would be really quite a feat

in terms of the manual, if it is section for section similar, it would basically be the job of a translation software which is prevalent these days with even free ones directly on the web. they probably touched up the syntax errors etc so that it probably looked authentic

i take a quick look at the reference manual
for cs32f103
http://www.ckscup.com/upload/CS32F103%E … %86%8C.pdf
http://www.ckscup.com/material.aspx
vs rm0008
https://www.st.com/content/ccc/resource … 171190.pdf

based on the contents page some sections are apparently re-organised e.g. combined or omitted. interestingly
the chapter on fsmc and sdio, ethernet didn’t seem to be there in the cs322f103 chinese manual,
adc, dac, can, spi, i2c, usart are there, usb apparently omitted the otg parts, i’d guess the normal usb device mode is still there

apparently these seem to be the chapter mappings:
rm0008 - cs32103 (chinese)
chapter chapter context
2 1 document conventions / abbreviations
3 2 memory and bus architecture
4 3 CRC calculation unit
5 omitted! (power control PWR)
6 5 backup registers (BKP)
7 6 clocks and reset control (RCC)
8 omitted!: connectivity line devices: RCC
9 7 General-purpose and alternate-function I/Os (GPIOs and AFIOs)
10 8 Interrupts and events
11 10 Analog-to-digitalconverter (ADC)
12 11 Digital-to-analogconverter (DAC)
13 9 Direct memory access controller (DMA)
14 12 Advanced-controltimers (TIM1&TIM8) - only TIM1 is specifically mentioned in cs32f103
15 13 General-purpose timers (TIM2 to TIM5) (noted as TIMx in cs32f103 manual
some chapters on timers are apparently omitted
18 14 Real-timeclock (RTC)
19 15 Independent watchdog (IWDG)
20 16 Window watchdog (WWDG)
21 omitted! Flexible static memory controller (FSMC)
22 omitted! Securedigital input/output interface (SDIO)
23 17 Universalserial bus full-speed device interface (USB)
24 18 Controller area network (bxCAN)
25 19 Serialperipheral interface (SPI) .
26 20 Inter-integrated circuit (I2C) interface
27 21 Universal synchronous asynchronous receiver transmitter (USART)
28 omitted! USB OTG
29 omitted! Ethernet
30 22 Device electronic signature
31 23 Debug support (DBG) .


i’ve a strange feeling that if we can flash something in the ‘system boot’ flash rom area, then we’d have our own rom / bootloader as well.
just that that is *undocumented*. i.e. set boot0 to boot our own bootloader

[ag123 – Thu Feb 07, 2019 8:27 am] –
i’ve a strange feeling that if we can flash something in the ‘system boot’ flash rom area, then we’d have our own rom / bootloader as well.
just that that is *undocumented*. i.e. set boot0 to boot our own bootloader

That would be nice

[RogerClark – Thu Feb 07, 2019 9:00 am] –

[ag123 – Thu Feb 07, 2019 8:27 am] –
i’ve a strange feeling that if we can flash something in the ‘system boot’ flash rom area, then we’d have our own rom / bootloader as well.
just that that is *undocumented*. i.e. set boot0 to boot our own bootloader

That would be nice

Why for the CS32 and not for the STM32, then?

I am not sure it is a nice feature: it means that the BL is not in ROM and thus can be destroyed, so the only safe way to recover a bricked chip is by JTAG/SWD.

BTW, here is a disassembly of the STM32F103 original Serial bootloader ROM:
https://github.com/trebisky/stm32f103/b … t/boot.txt

i think the ‘once programmable’ setup is likely a flag stored in flash rather than a hardware fuse. hence even ‘system memory’ is likely simply flash memory.
as to ‘accidental overwriting’, well that is possible but then there are pros and cons, it is similar to the debate on libreboot which seek to replace the pc bios with a open sourced bios/boot.

[ag123 – Thu Feb 07, 2019 2:49 pm] –
i think the ‘once programmable’ setup is likely a flag stored in flash rather than a hardware fuse. hence even ‘system memory’ is likely simply flash memory.
as to ‘accidental overwriting’, well that is possible but then there are pros and cons, it is similar to the debate on libreboot which seek to replace the pc bios with a open sourced bios/boot.

Only a silicon die picture could tell if there is actual Mask ROM, OTP ROM or Flash memory. Only in the last case would it be possible to rewrite it.

But why do you suspect this on the CS32 and not on the STM32?

[Squonk42 – Thu Feb 07, 2019 4:52 pm] –
Only a silicon die picture could tell if there is actual Mask ROM, OTP ROM or Flash memory. Only in the last case would it be possible to rewrite it.

But why do you suspect this on the CS32 and not on the STM32?

yup, ditto, i’d think it is pretty much the case for stm32 too, the notion would be that it would possibly be cheaper to have a single architecture i.e. flash ram rather than a mix of roms and flash ram, though that could be done as well. it would be perhaps costly to build ‘blowable fuses’ vs say a single bit/byte register stored in flash. e.g. so that lets say if you flag that bit/byte as high, the corresponding flash memory section becomes non-programmable

as for cs32, if we assume that it is after all the same stm32’s mask, i’m not too sure if there is a possibility that the cloners couldn’t figure out the means to update system rom/flash area, that could explain the non-functioning uart bootloader (i.e. boot 0) if we assume that they’d want to make a ‘perfect clone’ that would also replicate stm32 boot loader behavior

You can make RAM and masked ROM using the same process as general CMOS, but Flash uses a different process and requires a lot of real estate on the die.

This is why today more and more chips (like the ESP8266/ESP32) only integrates a small bootloader ROM and move the Flash memory externally to a single/bi/quad SPI Flash chip (or bond it into the package for the GD32…). The STM32F7 value line is a mix in-between, with only a small Flash memory onboard.

As for the system-memory bootloader (ROM, OTP or Flash), the only way to figure out if it is the same would be to dump its contents into a file for both the CS32 and the STM32 and compare them. This can be done using the command:
$ st-flash read system.bin 0x1ffff000 2048
st-flash 1.5.1
2019-02-07T21:46:25 INFO usb.c: -- exit_dfu_mode
2019-02-07T21:46:25 INFO common.c: Loading device parameters....
2019-02-07T21:46:25 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-02-07T21:46:25 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes


Just to repost what I’ve posted to the EEVBlog…

The CS32 does not overclock very well

I added some more overclocking settings to my Core to do this testing.

And a STM32 BluePill worked fine right up to 128Mhz (16 multipler on the 8Mhz crystal)

But the fastest I could run the CS32 at was 80 Mhz (x 10 multiplier)

I checked the bit pattern for the x 10 vs x11 multipliers and the values are

RCC_PLLMUL_10 = (0x8 << 18),
RCC_PLLMUL_11 = (0x9 << 18),

So this doesn’t look like they simply reduced the number of bits in that the PLL has.

It simply looks like it won’t run as fast.

Note the GD32, runs fine at 120Mhz, so the CS32 probably isn’t based on the GD32

Are you able to flash it using the Serial bootloader?

If not, can you dump the system memory content into a file so we can check?

The Serial Bootloader worked ok

I have not had time to try dumping the bootloader

OK, thanks!

If it is working as expected, it is probably 100% compatible and thus it is not useful to dump it.

I tried to dump that address using my PC, but ST’s own flash gui doenst allow the address to be entered

ST’s command line until seems to crash when I try it

stm32flash.exe (the open source flash reader / writer), just creates an binary file with only 2 bytes in it

It looks like you are running the command on a linux machine.. Where did you download the application from ?

It is part of the official core. On my Linux box, its path is “~/.arduino15/packages/STM32/tools/STM32Tools/1.2.0/tools/linux64/stlink/st-flash” and requires to add “~/.arduino15/packages/STM32/tools/STM32Tools/1.2.0/tools/linux64/stlink/lib” to the LD_LIBRARY_PATH to load the “libstlink.so.1” shareed library.

Basically, move BOOT0 jumper to 1, leave BOOT1 to 0, reset the board, then:
$ export LD_LIBRARY_PATH=/home/mstempin/.arduino15/packages/STM32/tools/STM32Tools/1.2.0/tools/linux64/stlink/lib
$ ~/.arduino15/packages/STM32/tools/STM32Tools/1.2.0/tools/linux64/stlink/st-flash read system.bin 0x1ffff000 2048
st-flash 1.5.1
2019-02-07T21:46:25 INFO usb.c: -- exit_dfu_mode
2019-02-07T21:46:25 INFO common.c: Loading device parameters....
2019-02-07T21:46:25 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-02-07T21:46:25 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes

I’m not sure if the data is valid, but this is what I got when I used my PC’s version of the STLink CLI to dump that address

(See attached)

I also thought I’d try using STLink to write to that address, but it gets an error.

I guess its possible there is a secret register setup which may allow the address to be programmed but it would be virtually impossible to find out what that was, as it would be a trade secret

i’d guess when we put the various pieces of things together including this non working uart bootloader, the cs32 is possibly a clone of the original stm32 from the masks as otherwise it is also unlikely that the ‘bug’ of exposing the full 128k when c8 should be 64k is replicated.
industrial espionage? possibly, but my guess is these days masks are literally software hence it is fairly possible that the software masks is stolen.
nevertheless this is not proven, and it isn’t truly illegal to reverse engineer a chip aside from various copyright etc issues
either way, i don’t think serious manufacturers would consider cs32 as they would be accountable for product liability / warranties etc and they would want the original chip manufacturer to stand up for the product should problems happen and if it turns out it is in the stm32 chips itself

for the purpose of casual entertainment and experiments the cs32 could be interesting to try out just like all the other competing chips of esp8266, esp32 etc

another thing would be that the price isn’t all that different a real stm32 f1 cost say around $1 and cs32 sold for around 80 cents on aliexpress, it shows that even the cloners couldn’t beat the cost of manufacturing those chips, it is about as low as it gets

interestingly when i take a look at the dump from roger’s zip file, it appear to be some ‘random’ data which could be possibly codes i.e. the boot loader itself. hence i’m not too sure what could have caused the uart boot loader to fail.
oops my mistake, i think roger mentioned that the serial boot loader works

ok i did this using roger’s cs32 bin file.

convert that to elf
gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-objcopy --input-target=binary --output-target=elf32-little CS32_bootloader_dump.bin CS32_bootloader_dump.elf


@ag123

Thanks for the link.

20c saving on items which are produced by the thousand or million can be a big cost saving, but personally, after finding out that they don’t overclock very well, I think they are substandard to the STM32, and not simply a exact copy.

If the CS32 and only be overclocked to 80Mhz, I wonder if it will stop working, if I heat it to 50 deg C

Don’t draw a conclusion too fast: overclocking is working out of specs, and it can depend on temperature (I heard it is hot down there ), crystal and of course the MCU itself. And for the MCU, characteristics may vary from batch to batch in this regard, so a genuine STM32 may also fail in some cases.

As for liability, if it is not a problem for hobbyists, it is of course a problem for professionals if they have doubts regarding the origin of the chip.

With the CS32, the less we could say is that it is not clear. Unlike the GD32 which is clearly a different chip (even a different architecture if we consider the SPI Flash bonded die), it seems that the CS32 is a very close clone of the STM32, but we don’t know how legal it is, as this may be an STM authorized copy for some markets.

I don’t read Chinese, but based on Google translations, what you can find at http://www.ckscup.com is quite interesting: it looks like there is an initiative of the city of Wuxi near Shanghai, in collaboration with a company named “Beijing Zhaoyi Innovation Technology Co., Ltd” to create a attractive pole for IC manufacturing.

One sentence from this page is particularly puzzling:
6月25日，随着张素心董事长一声令下，华虹无锡项目提前两天开始首块筏板混凝土浇筑，这标志着项目F1生产厂房基础工程全面开始。从项目落地、资金到位、开工建设到基础工程开始，华虹在锡项目书写了集成电路产业的无锡速度、无锡质量、无锡标杆。

Which, according to Google, translates into something like:
On June 25, with the order of Chairman Zhang Suxin, the Huahong Wuxi project began the first concrete pouring of the concrete in two days in advance, which marked the beginning of the basic project of the F1 production plant.
What is the “F1” in this context? I would like to bet for the CS32F1

Mentioned Zhang Suxin is the Chairman of Hua Hong Semiconductor Co., a company focuses on the development and manufacture of 200mm wafer semiconductors with 1,0 µm to 90 nm technologies for RFCMOS, MEMS, analog and mixed signals processes, with an emphasis on non-volatile memories, power supply and… microcontrollers.

With 3 plants near Wuxi, Hua Hong Semiconductor is the world’s second largest 200mm pure wafer foundry based on total sales revenue in 2016, and through its 3 fabs in Shanghai, the company’s current 200mm wafer processing capacity is among the best in China, with a monthly capacity of approximately 170,000.

So it is not a small fish, here, we are talking of state-sponsored multi-billions investments…

But wait: further investigations lead me to this article:
https://www.eetimes.com/document.asp?doc_id=1159990#

It does not tell us if this CS32 chip is manufactured with STM’s consent or not, but at least it looks like STM and Hua Hong already worked together…

the lack of mention of STM in any corporate capacity shows that they did not involve stm in this particular setup
as to whether they are mask clones or reversed engineered, my guess is STM would probably investigate that further
i doubt STM have any license or joint venture agreements for 3rd parties to make the chips as STM would probably announce it themselves

From http://www.mesantek.com/news/shownews.php?lang=en&id=38:
As of the end of 2016, STMCU in China’s market share has reached 14.1%, China for the STM32 global market contributed 36% of the share, the annual compound growth rate reached a staggering 27%. In the domestic Cortex-M market, ST to 45.8% market share to become the second largest general-purpose MCU manufacturers. 20170718-ST-2 Figure: STMCU in China’s market share has reached 14.1%.
…
On March 14th this year, the only 12-inch fab in Crolles, France, was forced to close, and it might take several weeks to restart production, fearing the impact of the Samsung and Apple camera modules The France Crolles is one of ST’s most advanced production lines and one of Europe’s largest advanced fabs.
…
ST largest packaging plant is located in Shenzhen, China, and Shenzhen SEG Group joint venture named Saiyi Microelectronics Co., Ltd., began in 1996 in Futian Free Trade Zone operation. 2008 and in Longgang District, Shenzhen opened a new packaging plant, but closed in 2013 and merge into the Italian microelectronics. At present, STMicroelectronics is working with the Chinese foundry company Hua Hong NEC Electronics Co., Ltd. (located in Shanghai) rubbing business in China to build 12-inch processing plant.

All this looks like very bad translations, but you can understand that despite the fact that STM has its own fabs, it looks like STM has no longer the capacity to produce the chips, and it may indeed turning to Hua Hong/NEC for manufacturing STM23 chips for the domestic Chinese market…

I still can’t get the serial bootloader to work on mine. It doesn’t even seem to be trying in any way, the regular program always runs whatever position the boot jumpers are in.
I’m also still pretty sure this one is only 64k, that’s what ST-link reports, and trying to flash more always fails.

What’s the value of the R10 resistor on the blue pill board using this new chip?

[bootsector – Sun Feb 10, 2019 8:41 pm] –
What’s the value of the R10 resistor on the blue pill board using this new chip?

10K, same as for the “original” Bluepill, see viewtopic.php?f=3&t=4522&start=30#p53060

Sorry I’ve overlooked that informative post. Thank you!

[deathterrapin – Sun Feb 10, 2019 1:30 pm] –
I still can’t get the serial bootloader to work on mine. It doesn’t even seem to be trying in any way, the regular program always runs whatever position the boot jumpers are in.
I’m also still pretty sure this one is only 64k, that’s what ST-link reports, and trying to flash more always fails.

I’m using STM’s flash “Demonstrator” to connect to the bootloader, I have not tried the tool that’s in my core

Re 64k

Perhaps the yield is not as good as on STMs fab plants, hence not all chips have 128k.

But I think that the STLink CLI on windows reported 128k, however I would need to double check.

I have 3 boards, so I better solder pins to the other 2 and test them

there are some particularities for stm32 serial uart boot loaders

https://www.st.com/content/ccc/resource … 264342.pdf
1 USART bootloader code sequence (page 5)
one start bit, 0x7F data bits,
even parity bit and one stop bit

but i’d guess normally the appropriate s/w e.g. https://pypi.org/project/stm32loader/ and serial dongle would take care of it

I’ve received some of these devices, I ordered them without noticing they were not STM32s.

If you want to use texane/stlink to write the bootloader:
– All of the boards I have received had their memory write protected, the only solution I have found was to remove the flag by using ST Link Utility (on Windows) as texane/stlink does noes support removing this flag.
– You need to tweak the source code of texane/stlink because the chip_id is not the same as the other Blue Pills, see https://github.com/texane/stlink/pull/757/files. Note that this modification WILL break uploading on other platform, as the same chip_id is shared between two different platforms (see https://github.com/texane/stlink/issues … -462068740)

cs32 is featured on cnx-software
https://www.cnx-software.com/2019/02/10 … ill-board/

I just received my c32 clones, I could flash the DFU bootloader with STLink utility without any problems.
And I have USB serial output on both boards.
I did not try to flash more than 64k yet.

ditto, just received and i managed to get the on chip uart boot loader to work as well
viewtopic.php?f=3&t=4572
mine has got 128k flaash, as flash checks and the flash erase seem to imply it

I asked ST whether this was a licensed copy or not and they replied that it was not, just FYI, wouldn’t use this in anything not for hobby/personal use: https://m.imgur.com/a/gy30PqN

They wrote “CS32F10C8” is not a legit copy..