Electronics > Beginners
CS32F103C8T6 datasheet and tests (was:"UNEXPECTED idcode" flashing bluepill)
<< < (6/10) > >>
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: ---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.
--- End code ---

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 :horse: 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:

--- Quote from: Macbeth on October 02, 2019, 05:20:03 pm ---In the log file it shows readJEP106ID():  Vendor = 0x55 and I'm guessing that isn't ST Micro.

--- End quote ---

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: ---0xe00fffc0: 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000
0xe00fffe0: 00000010 00000004 0000000a 00000000 0000000d 00000010 00000005 000000b1

--- End code ---

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: ---0xE00FFFC0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ................................
0xE00FFFE0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000  ................................

--- End code ---

 :-//
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 :-DD

 

Yeah, but no, I wanted the STM32 specifically for its USB as I want to play with HID and maybe USBTMC.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod