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

[RogerClark]

Yes.

I could try increasing the wait states, as this would probably make it run at higher clock rates.

BTW.

There is a post about this on www.cnx-software.com

https://www.cnx-software.com/2019/02/10/cs32-mcu-stm32-clone-bluepill-board/


There is also speculation that perhaps these devices are coming out of the back door of ST's own fab plants, and are devices which have failed some of the testing, e.g. speed testing ??
But I think this is unlikely, as they'd not want to badge them as something different, and could easily pass them off as STM32F103C8's since they seem to work OK.

And the ID code is also different, which makes this idea even less likely.

[ak634]

Sorry for necro posting, I found this topic searching for 0x2ba01477 after having problems with connecting to a new board.

Can legitimate STM32F103C8T6 come with this SWD ID? The one on my board is marked as real STM32 but reports 0x2ba01477. I wonder if it is a relabelled clone or ST started to package a different generation of ARM cores. I could not find a list of IDs online but 0x2ba01477 seems to belong to M4 cores.

Another weird thing is that it does not seem to be affected by both BOOT pins and always runs code from the flash.

[Macbeth]

I've a couple of STM32F103C8T6 bluepill boards that I've so far been programming using serial. I never could get any of the STM32duino-bootloaders working, even after replacing the 10K USB pullup resistor with 1K5.

I received an Aliexpress ST-LINK V2 today and have been tearing my hair out trying to get it to work with STM32CubeIDE. I updated its firmware to V2J34S7 no problem, and the bluepill can be programmed using ST-LINK Utility just fine. It identifies as Device ID:0x410, flash Size : 64KBytes, Device family :STM32F10xx Medium-density.

Trying to debug using the STM32CubeIDE (ST-LINK GDB server) probe fails with

Code: [Select]

Hardware watchpoint supported by the target
SWD frequency = 4000 kHz
ST-LINK Firmware version : V2J34S7
Device ID: 0x410
PC: 0x80052c4
ST-LINK device status: HALT_MODE
ST-LINK detects target voltage = 3.26 V
Vendor = 0x55

Error in initializing ST-LINK device.
Reason: ST-LINK: Could not verify ST device! Abort connection.
In the log file it shows readJEP106ID():  Vendor = 0x55 and I'm guessing that isn't ST Micro.

I gave up on ST-LINK GDB Server Switched the probe to (ST-LINK OpenOCD) and then got the same UNEXPECTED idcode: 0x2ba01477 error as the OP.

Thankfully I found this thread 

I replaced the set _CPUTAPID 0x1ba01477 as suggested by tsman in the ...\resources\openocd\st_scripts\target\stm32f1x.cfg file and also had to set the generator options to connection speed 4MHz and reset mode to software. Debugging is now working with STM32CubeIDE 

I'm also using Visual Studio Code with Platform IO. I had to modify the ...\.platformio\packages\tool-openocd\scripts\target\stm32f1x.cfg file to get that working.

The dodgy bluepill boards purport to have proper STM32 chips. See attached.

[ak634]

In the log file it shows readJEP106ID():  Vendor = 0x55 and I'm guessing that isn't ST Micro.

It is interesting the JEP106 showed up. I have a few bluepills with the chip similar to yours, see my post above. The JEDEC JEP106 identification is stored in 0xe00fffc0 - 0xe00fffff. Can you dump yours?

My *original* (who knows, but) stm32 had the following:

Code: [Select]

0xe00fffc0: 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000
0xe00fffe0: 00000010 00000004 0000000a 00000000 0000000d 00000010 00000005 000000b1

which indeed identify ST Micro, continuation code = 0 and vendor code = 0x20. But the the new one has all zeros. So I wonder how ST Link reads this data.

Code: [Select]

0xE00FFFC0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ................................
0xE00FFFE0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ................................

 

[Macbeth]

Both my dodgy STM32 Blue Pills have this signature (attached). They do not work with any of the stm32duino USB boot loaders even with the R10 change to a 1.5k ohm. They do not enumerate in Windows or Linux. I also tried some example 'closer to bare metal' code using STM32CubeIDE examples for a serial to USB and that wouldn't enumerate either. I figured these dodgy STM32s just have a crippled USB port but then I flashed 'mecrisp' which is an implementation of Forth running over its own USB serial and it works perfectly! Very odd.

This poor guy has been through the rinser with I'm sure the same POS blue pill and has resorted to a custom serial programming board

 

Yeah, but no, I wanted the STM32 specifically for its USB as I want to play with HID and maybe USBTMC.

[ak634]

The format of these registers is in CoreSight Architecture Specification Section B2.2.2 PIDR0-PIDR7, Peripheral Identification Registers

0xfec PIDR3
0xfe8 PIDR2
0xfe4 PIDR1
0xfe0 PIDR0
0xfdc PIDR7
0xfd8 PIDR6
0xfd4 PIDR5
0xfd0 PIDR4

JEDEC, PIDR2 bits[3]  Must be 0b1 to indicate that a JEDEC-assigned value is used.

DES_0, PIDR1 bits[7:4] JEP106 identification code bits[3:0].
DES_1, PIDR2 bits[2:0] JEP106 identification code bits[6:4].
DES_2, PIDR4 bits[3:0] JEP106 continuation code.

PART_0, PIDR0 bits[7:0] Part number bits[7:0].
PART_1, PIDR1 bits[3:0] Part number bits[11:8].

JEP106 code seems to be a placeholder: JEDEC = 0 (must be 1), continuation code 0x5, ID code 0x55.
Part number is 0x29b, which is different from 0x410 in STM32.

[Macbeth]

Looks like I missed the last words, FWIW they are the same as yours:

0xE00FFFF0:  0000000D  00000010  00000005  000000B1

[ak634]

Looks like I missed the last words, FWIW they are the same as yours:

0xE00FFFF0:  0000000D  00000010  00000005  000000B1

Thanks, the previous dump actually was enough to read the identification info. I'm not sure if the chips are the same, but it appears in both cases they do not bear stm identification.

I am trying to make my USB stuff work on the clone with the "991KA" marking, and after a couple of nights debugging, it appeared USB does not receive setup packets correctly.

If anyone has USB communication working on this kind of clone or on the CS32, I would appreciate any pointers.

[Macbeth]

I haven't had a chance to do any further USB testing, but I did get this version of mecrisp Forth with USB serial console working on the "991KA". See if that works and if so perhaps there is a clue in the source code.

[ebastler]

I replaced the set _CPUTAPID 0x1ba01477 as suggested by tsman in the ...\resources\openocd\st_scripts\target\stm32f1x.cfg file and also had to set the generator options to connection speed 4MHz and reset mode to software. Debugging is now working with STM32CubeIDE 
[...]
The dodgy bluepill boards purport to have proper STM32 chips. See attached.

I am just running into the same problem: Bought a BluePill board (even from a local seller, since I was impatient); the µC claims to be a proper STM32 chip; but it has the 0x2ba01477 ID. Ready to edit the config file -- but I seem unable to even find it.   

I am using STM32CubeIDE, version 1.02. Where would the .cfg files live? In my project folder? In the "STM32CubeIDE" program folder hierarchy? I can't even find the "resource" folder which Macbeth helpfully gave as a starting point... Thanks for pointing me in the right direction!

EDIT: Ahh, got it now. For me, it's in C:\ST\STM32CubeIDE_1.0.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug_1.0.2.201907120816\resources\openocd\st_scripts\target. For whatever reason, the file search didn't find it when asking for the full "stm32f1x.cfg" name, but would find "*.cfg" right away. Grmpf...

[Macbeth]

Ah, sorry. I deliberately left the part of the path that contained dates and version numbers out.

As for Windows search and indexing, I loathe it and disabled mine ages ago. I've detested every windows search after XP.
I highly recommend the lightweight, astoundingly fast file search tool 'Everything' https://www.voidtools.com/ - it's a life changer! 

[ebastler]

Just downloaded "Everything" and took it for a quick spin. Wow, that's impressive indeed! I had not come across that tool -- thank you very much for pointing it out!

[ebastler]

While I am in the process of asking naive questions... (Hey, glad this thread happens to be in the "Beginners" section!) 

With a full installation of the STM32CubeIDE, where do I find the example source code from STM? I understand that an extensive collection of examples should be part of each "MCU package". I have installed the package for the STM32F1x, but for the life of me can't find a library of examples anywhere.

Thanks!

[Macbeth]

I don't know about an example code library, but STM32CubeMX will auto generate most of the HAL code for you. Unfortunately I can't use my STM32CubeIDE right now as I've just upgraded to latest version and it keeps popping up an error dialog when I try to start a new project - "Error downloading the following files: mcusFeaturesAndDescription.json (Timeout during download)" 

ETA: I followed this youtube for a USB Serial example


Note with STM32CubeIDE you do not need to start with MX and then link it to Eclipse like in the vid. STM32CubeIDE will call start MX for you when you launch a new project.

Now a problem with this dodgy bluepill is the USB example didn't work. I'll try it again with this upgraded version CubeIDE when I can finally download the above missing file 

[ebastler]

I don't know about an example code library, but STM32CubeMX will auto generate most of the HAL code for you.

Thanks! I have successfully used the CubeMX component (now nicely integrated into the IDE) to generate the initialization code for SPI, NVIC, various GPIOs and two timers. But the generated code does not go quite as far as I had hoped. E.g. one apparently has to call HAL_TIM_Base_Start_IT () to actually get things going, which I only found via random Googling. And I am not sure whether the IRS needs to do anything, e.g. to re-enable the interrupt. Where does one find that sort of information, in a more systematic way?

STM advertises here (https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html) that in the MCU packages,

"A large number of code use examples are also included making it even easier to get started"

The graphic near the bottom of that page links to the individual MCU packages; and my STM32CubeIDE states that it has the STM32F1 package installed. (Obviously, since it can generate code for the processor.)  So where are all those code use examples? 

[Macbeth]

I found the examples at %userprofile%/STM32Cube/Repository/STM32Cube_FW_F1_V1.8.0/Projects/STM32CubeProjectsList.html

[ebastler]

Hey, thank you very much for digging!
I'm heading home from the office right now to check on my computer. 

[ak634]

I haven't had a chance to do any further USB testing, but I did get this version of mecrisp Forth with USB serial console working on the "991KA". See if that works and if so perhaps there is a clue in the source code.

I tried it on one of my boards and unfortunately it did not work. Although it makes some progress during USB enumeration, it doesn't make it to create the console. The USB packet dump is full of truncated or empty packets sent from the device. I was able to make some progress with my code too, but essentially seeing similar problems.

Code: [Select]

>:~/stm32-test$ dmesg | tail
[833568.806235] usb 1-4: config index 0 descriptor too short (expected 67, got 64)
[833568.806240] usb 1-4: config 1 has an invalid descriptor of length 7, skipping remainder of the config
[833568.806245] usb 1-4: config 1 interface 1 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 2
[833568.807532] usb 1-4: New USB device found, idVendor=0483, idProduct=5740
[833568.807535] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[833568.807537] usb 1-4: Product: Forth Serial Port
[833568.807539] usb 1-4: Manufacturer: Mecrisp (STM32F10x)
[833568.807712] usb 1-4: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[833568.808141] cdc_acm 1-4:1.0: This device cannot do calls on its own. It is not a modem.
[833568.808149] cdc_acm: probe of 1-4:1.0 failed with error -22
>:~/stm32-test$ dmesg | tail
[833568.806235] usb 1-4: config index 0 descriptor too short (expected 67, got 64)
[833568.806240] usb 1-4: config 1 has an invalid descriptor of length 7, skipping remainder of the config
[833568.806245] usb 1-4: config 1 interface 1 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 2
[833568.807532] usb 1-4: New USB device found, idVendor=0483, idProduct=5740
[833568.807535] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[833568.807537] usb 1-4: Product: Forth Serial Port
[833568.807539] usb 1-4: Manufacturer: Mecrisp (STM32F10x)
[833568.807712] usb 1-4: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[833568.808141] cdc_acm 1-4:1.0: This device cannot do calls on its own. It is not a modem.
[833568.808149] cdc_acm: probe of 1-4:1.0 failed with error -22
>:~/stm32-test$ dmesg | tail
[833568.807712] usb 1-4: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[833568.808141] cdc_acm 1-4:1.0: This device cannot do calls on its own. It is not a modem.
[833568.808149] cdc_acm: probe of 1-4:1.0 failed with error -22
[833613.885577] usb 1-4: USB disconnect, device number 58
[833614.157665] usb 1-4: new full-speed USB device number 59 using xhci_hcd
[833614.269936] usb 1-4: Device not responding to setup address.
[833614.473905] usb 1-4: Device not responding to setup address.
[833614.678026] usb 1-4: device not accepting address 59, error -71
[833615.198306] usb 1-4: new full-speed USB device number 60 using xhci_hcd
[833615.310424] usb 1-4: device descriptor read/64, error -71
>:~/stm32-test$ dmesg | tail
[833568.807712] usb 1-4: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[833568.808141] cdc_acm 1-4:1.0: This device cannot do calls on its own. It is not a modem.
[833568.808149] cdc_acm: probe of 1-4:1.0 failed with error -22
[833613.885577] usb 1-4: USB disconnect, device number 58
[833614.157665] usb 1-4: new full-speed USB device number 59 using xhci_hcd
[833614.269936] usb 1-4: Device not responding to setup address.
[833614.473905] usb 1-4: Device not responding to setup address.
[833614.678026] usb 1-4: device not accepting address 59, error -71
[833615.198306] usb 1-4: new full-speed USB device number 60 using xhci_hcd
[833615.310424] usb 1-4: device descriptor read/64, error -71


[adamfxtion]

I am also having similar problems with USB enumeration and recent STM32 blue pill boards.
I did however find that using the opencm3 CDC example compiled in Platformio/VSC,  (all updated to most recent version, source code from https://raw.githubusercontent.com/libopencm3/libopencm3-examples/master/examples/stm32/f1/stm32-maple/usb_cdcacm/cdcacm.c) did allow these modules to enumerate successfully for me in Windows 10 (See screenshot), with it coming up as a Serial port in device manager. It does not actually work once I try to open it with a terminal, but I think that is because the example does not actually have the necessary support. I have also attached a compiled version for test purposes.

[Macbeth]

@ak634 - Hmm, I've been using Windows 10 and putty to connect. So I decided to test it on Ubuntu 18.04 and it works for me. Tested using sudo screen /dev/ttyACM0

dmesg:

Code: [Select]

[   69.229951] usb 1-5: new full-speed USB device number 6 using xhci_hcd
[   69.490083] usb 1-5: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[   69.490087] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   69.490089] usb 1-5: Product: Forth Serial Port
[   69.490091] usb 1-5: Manufacturer: Mecrisp (STM32F10x)
[   69.490092] usb 1-5: SerialNumber: 1D686BD9
[   69.507525] cdc_acm 1-5:1.0: ttyACM0: USB ACM device

@adamfxtion - Thanks for this! I hadn't tried libopencm3 yet, just Arduino and CubeMX.

This one nearly works in Win 10 (as you say it enumerates and allocates a COM port in device manager) but I can't connect to it. However it works fine in linux as /dev/ttyACM0. It's dmesg is pretty much as above.

Wireshark logs of this example vs mecrisp shows Windows is sending USBCOM protocol GET LINE CODING Requests and this code example is not returning anything, while the mecrisp is answering these requests with an "Unknown type 21 Status" packet.

[ak634]

I am also having similar problems with USB enumeration and recent STM32 blue pill boards.
I did however find that using the opencm3 CDC example compiled in Platformio/VSC, ....

Thanks @adamfxtion, this version was actually the best performing. There are a small number of "malformed" packets reported by Wireshark, but they were retried and I could actually type in the console. I will probably conclude that the USB in these devices should not be relied upon, and my samples seem to come from a somewhat more defective batch. The problem (in my devices) is truncated packets sent from the devices. The errors could be due to sensitivity to timing or power supply. I am giving up for now and will use these boards for less demanding work.

For completeness, my dumps are below. This is with the Forth console:

Code: [Select]

  1 0.000000000         host -> 55.0         USB 64 GET DESCRIPTOR Request DEVICE
  2 0.000044000         55.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE[Malformed Packet]
  3 0.000060000         host -> 55.0         USB 64 GET DESCRIPTOR Request DEVICE
  4 0.000149000         55.0 -> host         USB 82 GET DESCRIPTOR Response DEVICE
  5 0.000178000         host -> 55.0         USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
  6 0.000242000         55.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE QUALIFIER[Malformed Packet]
  7 0.000268000         host -> 55.0         USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
  8 0.000338000         55.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE QUALIFIER[Malformed Packet]
  9 0.000361000         host -> 55.0         USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
 10 0.000431000         55.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE QUALIFIER[Malformed Packet]
 11 0.000455000         host -> 55.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 12 0.000524000         55.0 -> host         USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]
 13 0.000547000         host -> 55.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 14 0.000598000         55.0 -> host         USB 73 GET DESCRIPTOR Response CONFIGURATION
 15 0.000616000         host -> 55.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 16 0.000694000         55.0 -> host         USB 73 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]
 17 0.000723000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 18 0.000798000         55.0 -> host         USB 68 GET DESCRIPTOR Response STRING
 19 0.000815000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 20 0.000883000         55.0 -> host         USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]
 21 0.000886000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 22 0.000977000         55.0 -> host         USB 100 GET DESCRIPTOR Response STRING
 23 0.000980000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 24 0.001017000         55.0 -> host         USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]
 25 0.001020000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 26 0.001114000         55.0 -> host         USB 104 GET DESCRIPTOR Response STRING
 27 0.001117000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 28 0.001154000         55.0 -> host         USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]
 29 0.001157000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 30 0.001431000         55.0 -> host         USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]
 31 0.001434000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 32 0.001471000         55.0 -> host         USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]
 33 0.001474000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 34 0.001752000         55.0 -> host         USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]
 35 0.001768000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 36 0.001811000         55.0 -> host         USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]
 37 0.001833000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 38 0.002035000         55.0 -> host         USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]
 39 0.002052000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 40 0.002126000         55.0 -> host         USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]
 41 0.002143000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 42 0.002374000         55.0 -> host         USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]
 43 0.002391000         host -> 55.0         USB 64 GET DESCRIPTOR Request STRING
 44 0.002459000         55.0 -> host         USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]
 45 0.002612000         host -> 55.0         USB 64 SET CONFIGURATION Request


This is with opencm3 example sent by @adamfxtion:

Code: [Select]

  1 0.000000000         host -> 90.0         USB 64 GET DESCRIPTOR Request DEVICE
  2 0.000114000         90.0 -> host         USB 82 GET DESCRIPTOR Response DEVICE
  3 0.000141000         host -> 90.0         USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
  4 0.000200000         90.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE QUALIFIER[Malformed Packet]
  5 0.000224000         host -> 90.0         USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
  6 0.000278000         90.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE QUALIFIER[Malformed Packet]
  7 0.000300000         host -> 90.0         USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
  8 0.000359000         90.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE QUALIFIER[Malformed Packet]
  9 0.000386000         host -> 90.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 10 0.000423000         90.0 -> host         USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]
 11 0.000446000         host -> 90.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 12 0.000507000         90.0 -> host         USB 73 GET DESCRIPTOR Response CONFIGURATION
 13 0.000531000         host -> 90.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 14 0.000564000         90.0 -> host         USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]
 15 0.000568000         host -> 90.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 16 0.000660000         90.0 -> host         USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]
 17 0.000663000         host -> 90.0         USB 64 GET DESCRIPTOR Request CONFIGURATION
 18 0.000816000         90.0 -> host         USB 131 GET DESCRIPTOR Response CONFIGURATION
 19 0.000822000         host -> 90.0         USB 64 GET DESCRIPTOR Request STRING
 20 0.000917000         90.0 -> host         USB 68 GET DESCRIPTOR Response STRING
 21 0.000921000         host -> 90.0         USB 64 GET DESCRIPTOR Request STRING
 22 0.001030000         90.0 -> host         USB 90 GET DESCRIPTOR Response STRING
 23 0.001034000         host -> 90.0         USB 64 GET DESCRIPTOR Request STRING
 24 0.001166000         90.0 -> host         USB 116 GET DESCRIPTOR Response STRING
 25 0.001190000         host -> 90.0         USB 64 GET DESCRIPTOR Request STRING
 26 0.001291000         90.0 -> host         USB 74 GET DESCRIPTOR Response STRING
 27 0.001769000         host -> 90.0         USB 64 SET CONFIGURATION Request
 28 0.001801000         90.0 -> host         USB 64 SET CONFIGURATION Response
 29 0.003141000         host -> 90.0         USBCOM 71 SET LINE CODING Request
 30 0.003192000         90.0 -> host         USB 64 URB_CONTROL out


Note that DEVICE QUALIFIER "malformed" packets are expected as the device probably does not support them. There are two "malformed" GET configuration descriptor responses, but every other are good.

[adamfxtion]

Just for the sake of completeness, I swapped one of the STM32's on a non working board with a Farnell UK sourced part, after which the board worked entirely as expected.
Taken together with the different chip ID, it seems certain  that the chips are not actually ST parts and so any of these boards may well not work as expected, certainly for the USB, but quite possibly for other peripherals too.
It is one thing getting a different chip with appropriate marking, but mislabeled parts make them too big a gamble for me that taints all the STM32 system minimum boards, with it all but impossible to ensure any quality standard at all. Which is a great shame, as I really liked these boards otherwise.
And a picture of the part ordered from Farnell - Quality of the printing looks much better to me than the part originally supplied and also doesn't have the extra pair of dimples in the top.

[mikerj]

ST seem to be keeping very quiet about about the proliferation of these suspect devices.

[Macbeth]

I today received two new bluepill boards. I was pleased to see nicer looking boards than my first two, until I noticed the STM32 had that 991KA label 

But these work perfectly!  An absolute breeze to debug using ST-LINK and USB works without issue   They even have the correct 1K5 resistor R10 on board.





Now for the bad board...



So the difference is the bad STM32 F103C8T6 is labelled 991KA 93 MYS 807 and it has 2 extra dimples. The marking is not as clear.

Also the PCB pinout labeling is very shoddy and it has a metal reset button whereas my good boards have a plastic reset button.

For what it's worth I purchased my crap boards for £3.01 from Aliexpress "Robotlinking Store" and got my good boards at "Shop912692 Store" for just £2.51 delivered.