CS32F103C8T6 datasheet and tests (was:"UNEXPECTED idcode" flashing bluepill)

[Jaunedeau]

Hi,

  I bought an STM32F103C8T6 bluepill from aliexpress together with an ST-LINK V2. The st-link seems ok : I would reflash it with latest firmware using. The board has a chip which is not marked as ST STM32F103C8T6 but as CKS CS32F103C8T6 which seems to be advertised as a replacement clone.

  When I try flashing using OCD, I get an error about a similar but not identic idcode (0x2ba01477 instead of 0x1ba01477):

Code: [Select]

>openocd -f interface/stlink-v2-1.cfg -f target/stm32f1x.cfg
GNU MCU Eclipse 64-bit Open On-Chip Debugger 0.10.0+dev-00352-gaa6c7e9b (2018-10-20-06:24)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v32 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.213236
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x1ba01477
in procedure 'init'
in procedure 'ocd_bouncer'

It seems that the CKS clone is not reporting the proper idcode, but when I run the stlink utility, it recognises the mcu as an STM32F10XX (see attachment)

Is there something I did wrong ? Is the idcode in the latest stable OpenOCD wrong for stm32f103 ? Something weird with the clone ?

Thank you,
John.

[tsman]

The difference is the revision has changed for the SW-DP ID. It isn't identifying the uC itself. You can work around it by adding "set CPUTAPID 0x2ba01477" to the cfg file. Probably should just make a cs32f1x.cfg for it. The ST-Link tool is either ignoring the DPIDR entirely or masking off the revision bits so doesn't care. It identifies the uC by reading a different field.

Hmm. Interesting. First time I've seen this compatible clone. It used to just be GigaDevices with their GD32 compatible clones but now there is this CKS CS32 as well it seems. I wonder if it is the same arrangement with a standalone flash die bonded to the uC die inside the package. It isn't a clone of the STM32 silicon since it has some differences like this SW-DP DPIDR change.

[RogerClark]

Does anyone have a link to the datasheet for this new device ?

I've ordered 2 BluePills which claim to use it, just to see how compatible it is with the STM32

IMHO the GD32 isn't quite as compatible as it first seemed to be, because it had extended features using Reserved bits in various control registers, which could result in unexpected behaviors. And the zero wait state instruction execution because the flash was mirrored into RAM, could also cause timing problems
etc

 

[Jaunedeau]

I did not search for too long, but didn't find the datasheet.

I seems that the manufacturer is China Key System & Integrated  Co. Ltd, but the CK32F103 is not listed on their website : http://www.cksic.com/en/IC/234.html

I sent an email to them bu did not receive an answer. If you manage to find something please post it in this topic, I will change the topic accordigly

[Jaunedeau]

IMHO the GD32 isn't quite as compatible as it first seemed to be,

My cheap is marked CS32, not GD32, I don't know if they are the same chips.

[RogerClark]

Thanks to @Just4Fun on the stm32duino.com forum , here is a link to the datasheet

http://www.ckscup.com/upload/CS32F103%E6%89%8B%E5%86%8C.pdf

Unfortunately its in Chinese, and its too big for Google translate to convert


One point of interest is that the claimed SRAM size is 64k, in the datasheet for the CS32F103C8 version whereas the STM32F103C8 only has 20k
However its possible that the cut and pasted the whole datasheet from the Chinese version of the STM32F103 series and didn't bother to update individual values to match what the C8 version has.

[Jaunedeau]

Great news

One point of interest is that the claimed SRAM size is 64k, in the datasheet for the CS32F103C8 version whereas the STM32F103C8 only has 20k
However its possible that the cut and pasted the whole datasheet from the Chinese version of the STM32F103 series and didn't bother to update individual values to match what the C8 version has.

I can test that tomorrow

[RogerClark]

OK

FYI.

I'm currently trying to get the datasheet PDF translated using Chrome.
It will probably end up as a html page, so won't be perfect, but will be better than nothing

[RogerClark]

Its not perfect, as its lost some formatting, but here is a link to the PDF of the datasheet which I converted to HTML then ran a translator on, and then saved back as a PDF


https://drive.google.com/open?id=1dsH1QbDJNRaqphIb7adMx-BliQag9xj0

BTW. I don't think this the correct place for this thread.

Moderators please more it somewhere more appropriate.

[Jaunedeau]

One point of interest is that the claimed SRAM size is 64k, in the datasheet for the CS32F103C8 version whereas the STM32F103C8 only has 20k
However its possible that the cut and pasted the whole datasheet from the Chinese version of the STM32F103 series and didn't bother to update individual values to match what the C8 version has.

I can confirme that I could acces an array of 4803 u32, but not an array of 5003 u32 (the code is compiled in Rust, the led blinking and loops probably take more than the 468 bytes that should be left).

[ebclr]

Chinese seller say the folowing

CS32F103C8T6 QFP48 completely replaces STM32F103C8T6 PIN TO PIN spot

[tsman]

I can confirme that I could acces an array of 4803 u32, but not an array of 5003 u32 (the code is compiled in Rust, the led blinking and loops probably take more than the 468 bytes that should be left).

Did you alter the linker script?

[Jaunedeau]

I can confirme that I could acces an array of 4803 u32, but not an array of 5003 u32 (the code is compiled in Rust, the led blinking and loops probably take more than the 468 bytes that should be left).

Did you alter the linker script?

I think I did, but later found that another linked script comes the hardware abstraction layer I use (and this one if automatically downloaded at build so I still have to test using a local modified copy)

[RogerClark]

Trying to declare large arrays into RAM would not necessarily be a valid test, even if you changed the linker settings, unless you then wrote and read back the array

A much simpler way is just to use a pointer to the start of RAM and and write and read back a byte then increment the pointer until you no longer get the correct value.
In fact you should write 2 different values e.g. 0x55 and 0xaa or 0xff and 0x00 (I prefer the former), in case you read back either 0x00 or 0x00 when there is undefined memory

I guess perhaps rust does not allow this, but I think you are making life difficult for yourself by not using C, since this is an unknown processor, and AFIK rust on embedded is not as stable as C on embedded.

[Doctorandus_P]

Now I'm curious why you bought the CS32F103C8T6.
Is it really worth saving a few cents and stuggling with the incompatibilies and differenced compared to the STM32F103C8T6?

If you were represenenting a big company and expecting to sell millions of these could underdstand, but then you would have better leverage to get datasheets directly from the manufacturer.

There is also some info on the CS32 thingie on stm32duino.com.
Oops, I think that was about the GDS32F.... Are those the same?

[RogerClark]

GD32 and CS32 appear to be different devices

I think the OP bought a BluePill board which he expected to use a STM32 but has a CS32 on it

I deliberately ordered some of the CS32 boards as a matter of general interest

[Jaunedeau]

I think the OP bought a BluePill board which he expected to use a STM32 but has a CS32 on it

Exactly, I like to order the cheapest parts on aliexpress and  see what happens. This is how I learned to usemy oscilloscop

[RogerClark]

I received my CS32F103C8  (BluePill) boards yesterday

I did some tests and had no problem flashing using my ST-Link as the device reported the same ID code as a STM32F103C8 (0x410)

Except ST-Link reported the CS32F103C8 had 128k Flash and it reports the STM32F103C8 has 64k Flash (even though the STM32F103C8 actually has 128k)

I wrote a 128k file of random bytes (e.g. from dev/random) and verified that the whole file had been written to Flash. So the CS32F103C8 definitely appears to have 128k Flash

I tried changing the linker settings to increase the amount of RAM for a test application, but the application would not run if I changed the RAM size to more than the 20k which the STM32F103C8 has.

I also wrote some code to try to access RAM above the 20k boundary, and the code asserted, which again validates that the CS32F103C8 has the same 20k RAM size as the STM32F103C8

I've not done any more testing apart to install a USB bootloader and an application that used USB and the GPIO connected to PC13 and that all worked OK.

[iMo]

How is it with overclocking?

[RogerClark]

I tried running a "blink" application at 128Mhz overclock , but it failed.

However this isn't conclusive, as I'd need to confirm whether the same application works OK on a STM32, in case I screwed up with the test.


 

[iMo]

128MHz overclock is a standard option in your core, you would need an usb serial dongle however. Serial1 based tests should work fine @128M (with stm32).

[RogerClark]

Yes.

I know it has the 128Mhz option

Thats what I tried and blink didnt seem to work, but I need to setup and check the same sketch on a STM32 BP just to confirm that the CS32 does not work at 128Mhz

[RogerClark]

Interesting

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

[I wanted a rude username]

the fastest I could run the CS32 at was 80 Mhz

Could this mean the CS32 has lower headroom for high temperature operation?

The translated datasheet doesn't address operating temperature (or power consumption!), whereas the STM32F103 datasheet lists all of this in Table 9 (General operating conditions), giving a range of -40 to 85/105 °C depending on model.

[iMo]

Yeah, all my stm32f103xx work fine at 128M. GD is flash-less chip so it may run even faster.
With the CS clone you may try to increase its number of flash wait states to achieve a higher clock. The default setting would be 2, try it with 3.
PS: you may add the "Number of flash WS" selection into your core