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

[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.