CS32F103C8T6 datasheet and tests (was:"UNEXPECTED idcode" flashing bluepill) - Page 1
Forum section: electronics / beginners

author: Jaunedeau
author_rank: Regular Contributor
timestamp: January 10, 2019, 01:26:19 pm
content: 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:>openocd -f interface/stlink-v2-1.cfg -f target/stm32f1x.cfgGNU MCU Eclipse 64-bit Open On-Chip Debugger 0.10.0+dev-00352-gaa6c7e9b (2018-10-20-06:24)Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlWARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfgInfo : 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/SWDadapter speed: 1000 kHzadapter_nsrst_delay: 100none separateInfo : Listening on port 6666 for tcl connectionsInfo : Listening on port 4444 for telnet connectionsInfo : Unable to match requested speed 1000 kHz, using 950 kHzInfo : Unable to match requested speed 1000 kHz, using 950 kHzInfo : clock speed 950 kHzInfo : STLINK v2 JTAG v32 API v2 SWIM v7 VID 0x0483 PID 0x3748Info : using stlink api v2Info : Target voltage: 3.213236Warn : UNEXPECTED idcode: 0x2ba01477Error: expected 1 of 1: 0x1ba01477in 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.

author: tsman
author_rank: Frequent Contributor
timestamp: January 10, 2019, 01:59:04 pm
content: 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.

author: RogerClark
author_rank: Contributor
timestamp: January 23, 2019, 10:21:28 am
content: 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 STM32IMHO 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 problemsetc

author: Jaunedeau
author_rank: Regular Contributor
timestamp: January 23, 2019, 11:10:53 am
content: 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.htmlI 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

author: Jaunedeau
author_rank: Regular Contributor
timestamp: January 23, 2019, 11:22:38 am
content: QuoteMy cheap is marked CS32, not GD32, I don't know if they are the same chips.

author: RogerClark
author_rank: Contributor
timestamp: January 23, 2019, 09:50:56 pm
content: Thanks to @Just4Fun on the stm32duino.com forum , here is a link to the datasheethttp://www.ckscup.com/upload/CS32F103%E6%89%8B%E5%86%8C.pdfUnfortunately its in Chinese, and its too big for Google translate to convertOne point of interest is that the claimed SRAM size is 64k, in the datasheet for the CS32F103C8 version whereas the STM32F103C8 only has 20kHowever 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.

author: Jaunedeau
author_rank: Regular Contributor
timestamp: January 23, 2019, 10:14:46 pm
content: Great newsQuote from: RogerClark on January 23, 2019, 09:50:56 pmI can test that tomorrow

author: RogerClark
author_rank: Contributor
timestamp: January 23, 2019, 10:36:14 pm
content: OKFYI.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

author: RogerClark
author_rank: Contributor
timestamp: January 24, 2019, 02:15:54 am
content: 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 PDFhttps://drive.google.com/open?id=1dsH1QbDJNRaqphIb7adMx-BliQag9xj0BTW. I don't think this the correct place for this thread.Moderators please more it somewhere more appropriate.

author: Jaunedeau
author_rank: Regular Contributor
timestamp: January 26, 2019, 04:17:45 pm
content: Quote from: RogerClark on January 23, 2019, 09:50:56 pmI 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).

author: ebclr
author_rank: Super Contributor
timestamp: January 26, 2019, 08:37:46 pm
content: Chinese seller say the folowingCS32F103C8T6 QFP48 completely replaces STM32F103C8T6 PIN TO PIN spot

author: tsman
author_rank: Frequent Contributor
timestamp: January 26, 2019, 08:45:27 pm
content: Quote from: Jaunedeau on January 26, 2019, 04:17:45 pmDid you alter the linker script?

author: Jaunedeau
author_rank: Regular Contributor
timestamp: January 26, 2019, 08:50:24 pm
content: Quote from: tsman on January 26, 2019, 08:45:27 pmI 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)

author: RogerClark
author_rank: Contributor
timestamp: January 27, 2019, 12:08:48 am
content: 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 arrayA 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 memoryI 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.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: January 27, 2019, 10:10:32 am
content: 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?

author: RogerClark
author_rank: Contributor
timestamp: January 27, 2019, 10:13:22 am
content: GD32 and CS32 appear to be different devicesI think the OP bought a BluePill board which he expected to use a STM32 but has a CS32 on itI deliberately ordered some of the CS32 boards as a matter of general interest

author: Jaunedeau
author_rank: Regular Contributor
timestamp: January 27, 2019, 10:29:12 am
content: Quote from: RogerClark on January 27, 2019, 10:13:22 amExactly, I like to order the cheapest parts on aliexpress and see what happens. This is how I learned to usemy oscilloscop

author: RogerClark
author_rank: Contributor
timestamp: February 07, 2019, 10:20:16 am
content: I received my CS32F103C8 (BluePill) boards yesterdayI 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 FlashI 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 STM32F103C8I'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.

author: iMo
author_rank: Super Contributor
timestamp: February 07, 2019, 08:20:33 pm
content: How is it with overclocking?

author: RogerClark
author_rank: Contributor
timestamp: February 08, 2019, 06:40:39 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: February 08, 2019, 06:47:14 pm
content: 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).

author: RogerClark
author_rank: Contributor
timestamp: February 09, 2019, 06:10:07 am
content: Yes.I know it has the 128Mhz optionThats 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

author: RogerClark
author_rank: Contributor
timestamp: February 09, 2019, 09:43:37 am
content: InterestingThe CS32 does not overclock very wellI 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 areRCC_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

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: February 10, 2019, 05:06:06 am
content: QuoteCould this mean the CS32 has lower headroom for high temperature operation?The translated datasheetdoesn't address operating temperature (or power consumption!), whereasthe STM32F103 datasheetlists all of this in Table 9 (General operating conditions), giving a range of -40 to 85/105 °C depending on model.

author: iMo
author_rank: Super Contributor
timestamp: February 10, 2019, 10:31:56 am
content: 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

author: RogerClark
author_rank: Contributor
timestamp: February 13, 2019, 06:31:31 am
content: 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 onwww.cnx-software.comhttps://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.

author: ak634
author_rank: Newbie
timestamp: September 30, 2019, 12:52:32 am
content: 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.

author: Macbeth
author_rank: Super Contributor
timestamp: October 02, 2019, 05:20:03 pm
content: 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 withCode:Hardware watchpoint supported by the targetSWD frequency = 4000 kHzST-LINK Firmware version : V2J34S7Device ID: 0x410PC: 0x80052c4ST-LINK device status: HALT_MODEST-LINK detects target voltage = 3.26 VVendor = 0x55Error in initializing ST-LINK device.Reason: ST-LINK: Could not verify ST device! Abort connection.In the log file it showsreadJEP106ID(): Vendor = 0x55and I'm guessing that isn't ST Micro.I gave up on ST-LINK GDB ServerSwitched the probe to (ST-LINK OpenOCD) and then got the sameUNEXPECTED idcode: 0x2ba01477error as the OP.Thankfully I found this threadI replaced theset _CPUTAPID 0x1ba01477as suggested by tsman in the...\resources\openocd\st_scripts\target\stm32f1x.cfgfile and also had to set the generator options to connection speed 4MHz and reset mode to software. Debugging is now working with STM32CubeIDEI'm also using Visual Studio Code with Platform IO. I had to modify the...\.platformio\packages\tool-openocd\scripts\target\stm32f1x.cfgfile to get that working.The dodgy bluepill boards purport to have proper STM32 chips. See attached.

author: ak634
author_rank: Newbie
timestamp: October 07, 2019, 05:39:27 am
content: Quote from: Macbeth on October 02, 2019, 05:20:03 pmIt 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:0xe00fffc0: 00000000 00000000 00000000 00000001 00000000 00000000 00000000 000000000xe00fffe0: 00000010 00000004 0000000a 00000000 0000000d 00000010 00000005 000000b1which 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:0xE00FFFC0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................0xE00FFFE0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................

author: Macbeth
author_rank: Super Contributor
timestamp: October 07, 2019, 11:34:29 pm
content: 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 boardYeah, but no, I wanted the STM32 specifically for its USB as I want to play with HID and maybe USBTMC.

author: ak634
author_rank: Newbie
timestamp: October 08, 2019, 12:55:44 pm
content: The format of these registers is in CoreSight Architecture Specification Section B2.2.2 PIDR0-PIDR7, Peripheral Identification Registers0xfec PIDR30xfe8 PIDR20xfe4 PIDR10xfe0 PIDR00xfdc PIDR70xfd8 PIDR60xfd4 PIDR50xfd0 PIDR4JEDEC, PIDR2 bits 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.

author: Macbeth
author_rank: Super Contributor
timestamp: October 08, 2019, 03:27:59 pm
content: Looks like I missed the last words, FWIW they are the same as yours:0xE00FFFF0: 0000000D 00000010 00000005 000000B1

author: ak634
author_rank: Newbie
timestamp: October 10, 2019, 03:36:42 pm
content: Quote from: Macbeth on October 08, 2019, 03:27:59 pmThanks, 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.

author: Macbeth
author_rank: Super Contributor
timestamp: October 11, 2019, 11:58:10 am
content: I haven't had a chance to do any further USB testing, but I did get this version ofmecrisp Forth with USB serial consoleworking on the "991KA". See if that works and if so perhaps there is a clue in the source code.

author: ebastler
author_rank: Super Contributor
timestamp: October 15, 2019, 07:36:17 pm
content: Quote from: Macbeth on October 02, 2019, 05:20:03 pmI 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...

author: Macbeth
author_rank: Super Contributor
timestamp: October 16, 2019, 09:25:32 am
content: 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!

author: ebastler
author_rank: Super Contributor
timestamp: October 16, 2019, 11:36:46 am
content: 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!

author: ebastler
author_rank: Super Contributor
timestamp: October 16, 2019, 11:42:21 am
content: 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!

author: Macbeth
author_rank: Super Contributor
timestamp: October 16, 2019, 12:12:25 pm
content: 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 exampleNote 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

author: ebastler
author_rank: Super Contributor
timestamp: October 16, 2019, 01:24:11 pm
content: Quote from: Macbeth on October 16, 2019, 12:12:25 pmThanks! 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,QuoteThe 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?

author: Macbeth
author_rank: Super Contributor
timestamp: October 16, 2019, 02:22:47 pm
content: I found the examples at%userprofile%/STM32Cube/Repository/STM32Cube_FW_F1_V1.8.0/Projects/STM32CubeProjectsList.html

author: ebastler
author_rank: Super Contributor
timestamp: October 16, 2019, 03:42:02 pm
content: Hey, thank you very much for digging!I'm heading home from the officeright nowto check on my computer.

author: ak634
author_rank: Newbie
timestamp: October 18, 2019, 01:19:56 am
content: Quote from: Macbeth on October 11, 2019, 11:58:10 amI 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:>:~/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

author: adamfxtion
author_rank: Newbie
timestamp: October 18, 2019, 10:37:16 am
content: 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 fromhttps://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.

author: Macbeth
author_rank: Super Contributor
timestamp: October 18, 2019, 03:12:27 pm
content: @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 usingsudo screen /dev/ttyACM0dmesg:Code:[ 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.

author: ak634
author_rank: Newbie
timestamp: October 18, 2019, 04:28:32 pm
content: Quote from: adamfxtion on October 18, 2019, 10:37:16 amThanks @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:1 0.000000000 host -> 55.0 USB 64 GET DESCRIPTOR Request DEVICE2 0.000044000 55.0 -> host USB 64 GET DESCRIPTOR Response DEVICE[Malformed Packet]3 0.000060000 host -> 55.0 USB 64 GET DESCRIPTOR Request DEVICE4 0.000149000 55.0 -> host USB 82 GET DESCRIPTOR Response DEVICE5 0.000178000 host -> 55.0 USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER6 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 QUALIFIER8 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 QUALIFIER10 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 CONFIGURATION12 0.000524000 55.0 -> host USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]13 0.000547000 host -> 55.0 USB 64 GET DESCRIPTOR Request CONFIGURATION14 0.000598000 55.0 -> host USB 73 GET DESCRIPTOR Response CONFIGURATION15 0.000616000 host -> 55.0 USB 64 GET DESCRIPTOR Request CONFIGURATION16 0.000694000 55.0 -> host USB 73 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]17 0.000723000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING18 0.000798000 55.0 -> host USB 68 GET DESCRIPTOR Response STRING19 0.000815000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING20 0.000883000 55.0 -> host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]21 0.000886000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING22 0.000977000 55.0 -> host USB 100 GET DESCRIPTOR Response STRING23 0.000980000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING24 0.001017000 55.0 -> host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]25 0.001020000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING26 0.001114000 55.0 -> host USB 104 GET DESCRIPTOR Response STRING27 0.001117000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING28 0.001154000 55.0 -> host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]29 0.001157000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING30 0.001431000 55.0 -> host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]31 0.001434000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING32 0.001471000 55.0 -> host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]33 0.001474000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING34 0.001752000 55.0 -> host USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]35 0.001768000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING36 0.001811000 55.0 -> host USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]37 0.001833000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING38 0.002035000 55.0 -> host USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]39 0.002052000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING40 0.002126000 55.0 -> host USB 66 GET DESCRIPTOR Response STRING[Malformed Packet]41 0.002143000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING42 0.002374000 55.0 -> host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]43 0.002391000 host -> 55.0 USB 64 GET DESCRIPTOR Request STRING44 0.002459000 55.0 -> host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet]45 0.002612000 host -> 55.0 USB 64 SET CONFIGURATION RequestThis is with opencm3 example sent by @adamfxtion:Code:1 0.000000000 host -> 90.0 USB 64 GET DESCRIPTOR Request DEVICE2 0.000114000 90.0 -> host USB 82 GET DESCRIPTOR Response DEVICE3 0.000141000 host -> 90.0 USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER4 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 QUALIFIER6 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 QUALIFIER8 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 CONFIGURATION10 0.000423000 90.0 -> host USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]11 0.000446000 host -> 90.0 USB 64 GET DESCRIPTOR Request CONFIGURATION12 0.000507000 90.0 -> host USB 73 GET DESCRIPTOR Response CONFIGURATION13 0.000531000 host -> 90.0 USB 64 GET DESCRIPTOR Request CONFIGURATION14 0.000564000 90.0 -> host USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]15 0.000568000 host -> 90.0 USB 64 GET DESCRIPTOR Request CONFIGURATION16 0.000660000 90.0 -> host USB 64 GET DESCRIPTOR Response CONFIGURATION[Malformed Packet]17 0.000663000 host -> 90.0 USB 64 GET DESCRIPTOR Request CONFIGURATION18 0.000816000 90.0 -> host USB 131 GET DESCRIPTOR Response CONFIGURATION19 0.000822000 host -> 90.0 USB 64 GET DESCRIPTOR Request STRING20 0.000917000 90.0 -> host USB 68 GET DESCRIPTOR Response STRING21 0.000921000 host -> 90.0 USB 64 GET DESCRIPTOR Request STRING22 0.001030000 90.0 -> host USB 90 GET DESCRIPTOR Response STRING23 0.001034000 host -> 90.0 USB 64 GET DESCRIPTOR Request STRING24 0.001166000 90.0 -> host USB 116 GET DESCRIPTOR Response STRING25 0.001190000 host -> 90.0 USB 64 GET DESCRIPTOR Request STRING26 0.001291000 90.0 -> host USB 74 GET DESCRIPTOR Response STRING27 0.001769000 host -> 90.0 USB 64 SET CONFIGURATION Request28 0.001801000 90.0 -> host USB 64 SET CONFIGURATION Response29 0.003141000 host -> 90.0 USBCOM 71 SET LINE CODING Request30 0.003192000 90.0 -> host USB 64 URB_CONTROL outNote 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.

author: adamfxtion
author_rank: Newbie
timestamp: October 18, 2019, 08:07:07 pm
content: 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.

author: mikerj
author_rank: Super Contributor
timestamp: October 19, 2019, 10:30:27 am
content: ST seem to be keeping very quiet about about the proliferation of these suspect devices.

author: Macbeth
author_rank: Super Contributor
timestamp: November 05, 2019, 03:36:56 pm
content: 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 labelBut these work perfectly! An absolute breeze to debug using ST-LINK and USB works without issueThey 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 93MYS 807and 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.