STM32F103T8U6 not recognized by cubeIDE as genuine

[anda3243]

Hello everyone

I have a MCU related issue. We are working on a new product, and we have just recieved our prototype boards. It is a small mainboard with the STM32F103T8U6 controller.
This is the little brother to the bluepill board. Bluepill is suposed to use the STM32F103C8T6. I know about the fakes, we are comming to that.

When connecting it to cubeIDE I get the following errors. (cubeIDE 1.8.0)

Launch terminated, could not verify ST device.

The chips were sold to us as genuine, so I am a bit pissed that they are not. Or maybe they are, I am just messing something up.

I have found this info for the bluepill. I have followed it but it does not help. There are several articles or threads describing the same fix.

https://community.st.com/s/question/0D50X0000BUjpxvSQB/error-in-initializing-stlink-device-reason-18-could-not-verify-st-device-abort-connection

I am using the openOCD, and I have modified that .cfg file.
 
Do you have any suggestions on how to proceed?
Is there any way to disable the process cubeIDE uses for checking the chips?
Should I use some different chip ID in the .cfg file? The chip I am using is smaller than the bluepill chip, so probably a different ID.
Are there some other options instead of cubeIDE? I like cubeIDE, but I might be willing to change. I am relatively new to programming, so I benefit from the visual interface and auto generated code to enable certain pins.


We are planning to use the CSKF103C8T6 chip in the final version of our product. It is a copy of STM32F103C8T6, and used in the bluepill boards. This chip has better availability, and is cheaper when buying it within China. And I think that them putting their own name on it is a good sign. Better than pretending to be an STM chip.

What is the deal with the fake chips. Is it allowed to use them in a legitimate product? Or is there some licensing issue? I am somewhat new to this.

[pcprogrammer]

With openocd you should see the ID it reads from the device. This ID will tell you if it is fake or not. (Google how this works in a terminal)

I had this type of problem before with bluepill's with a non ST MCU on it. By changing the ID in the openocd.cfg file to the one reported by openocd it worked without problems.

[BreakingOhmsLaw]

This may be of use to you - someone wrote a tool that checks for fake STM32F1:
https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html#

In my experience, bluepills and similar boards came with 65% fakes before chipageddon, now it's 100%.

[DavidAlfa]

+1 fake chip. Can you post pictures?
Try this, but last tiem I did so, although openOCD worked, the device did very weird things.

[Doctorandus_P]

The first thing to do is to start openOCD or some other command line utility and read out the identification of the chip.

This can clarify if you've just got some faulty board, or the chip itself is fake.
If the chip itself is fake, then both ask for a full refund, and give a negative review if you bougt it on Ebay / Ali / whatever.
If it's just a bad solder joint or a misplaced SMT part, then meh, shit happens with those cheap boards, and if you should not expect perfect boards if you do not pay for quality control.

LCSC is a reputable seller as far as I know, and the last time I checked (before chippageddon) there were at least 8 different manufacturers of pin (and mostly software) compatible chips with the xxx-32F103xxxx. If you buy at LCSC, then you can be reasonably sure the original part number is not erased or something else printed over it.

[westfw]

When connecting it to cubeIDE I get the following errors. (cubeIDE 1.8.0)
Launch terminated, could not verify ST device.

I guess that technically, you shouldn't be using the ST intellectual property (code generators, libraries, even the .h files) to develop code for non-ST chips.  It's not allowed by the licenses.  (no one ever pays much attention to those licenses that say "I'll only use the ST .h files on ST products, because they seem pretty silly.  Until there are clones.)

Although carrying that all the way through the IDE seems pretty excessive.
Sounds like a good reason not to use cubeIDE.

[anda3243]

Thank you for the replies. I will do some more attempts and get back to you.

[anda3243]

+1 fake chip. Can you post pictures?
Try this, but last tiem I did so, although openOCD worked, the device did very weird things.

Here are the boards. These are custom boards, not the regular bluepills.

I have tried the fix in the link you sent. I have not been able to make it work. I think I need to read out the ID from the chips I got.

[anda3243]

When connecting it to cubeIDE I get the following errors. (cubeIDE 1.8.0)
Launch terminated, could not verify ST device.

I guess that technically, you shouldn't be using the ST intellectual property (code generators, libraries, even the .h files) to develop code for non-ST chips.  It's not allowed by the licenses.  (no one ever pays much attention to those licenses that say "I'll only use the ST .h files on ST products, because they seem pretty silly.  Until there are clones.)

Although carrying that all the way through the IDE seems pretty excessive.
Sounds like a good reason not to use cubeIDE.

I guess that they are making money trough those licenses, and all these fake chips are endangering that.

Do you have some good recommendation on what to use instead of cubeIDE? I started to test things out and learn using cubeIDE and a genuine chip and it worked great.
Not too late to switch tho.

https://twitter.com/ADanebergs/status/1501031899594063872

[anda3243]

This is what I get from the console in cubeIDE. I have made many changes in the stm32f1x.cfg file
The changes include:
Changing from 0x1ba01477  to  0x2ba01477 and back in this line

#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0008 Section 26.6.3
      set _CPUTAPID 0x3ba00477
   } {
      # this is the SW-DP tap id not the jtag tap id
      set _CPUTAPID 0x20036410
   }
}

Changing this, expected ID should be 0
#swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0

I have tried adding this expression before the if statements

set CPUTAPID 0

and this expression

reset_config trst_only

This is the printout from the Console in cubeIDE. It is followed by the Could not verify the ST device statement. This printout does not change no matter what I change in the .cfg file. I get the feeling that the issue is elsewhere. The changes I make have no effect. 


Print starts:
Open On-Chip Debugger 0.11.0+dev-00438-ga75fc63 (2021-11-03-15:27)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J39S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.658746
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Error: BUG: can't assert SRST
Info : stlink_dap_op_connect(connect)
Error: BUG: can't assert SRST
Info : SWD DPIDR 0x2ba01477
Info : STM32F103T8Ux.cpu: Cortex-M3 r2p1 processor detected
Info : STM32F103T8Ux.cpu: target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32F103T8Ux.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : device id = 0x20036410
Info : flash size = 64kbytes
O.K.

O.K.:0xE00FFFD0

shutdown command invoked
Info : dropped 'gdb' connection
Print ends:


Is this my device ID?

Info : device id = 0x20036410

Any advice on how to continue is most welcome!!

[DavidAlfa]

Definitely ids are wrong, see RM0008 31.6, page 1086
Just edit the id, the reset options are available under the debug configuration tab, set "software reset" if you aren't connecting nRST, or hardware reset if so.

That id seems to match a CS32F103C8T6:
https://www.eevblog.com/forum/beginners/unexpected-idcode-flashing-bluepill-clone/

[anda3243]

Definitely ids are wrong, see RM0008 31.6, page 1086
Just edit the id, the reset options are available under the debug configuration tab, set "software reset" if you aren't connecting nRST, or hardware reset if so.

That id seems to match a CS32F103C8T6:
https://www.eevblog.com/forum/beginners/unexpected-idcode-flashing-bluepill-clone/

Thank you for the fast answer!

My questions might be beginner level. But I want to understand this, one little bit at the time.

So my device ID is 0x20036410? And I should put this ID in the .cfg file?


I should use openOCD right? As far as I read there is no chance to get this working with GDB server.
With openOCD selected I was not able to find any reset menu or reset options. I have added a 10k pullup resistor to the NRST pin. Even without the pullup the NRST voltage was nearly at the same level as VCC.

Thank you in advance!

[darkspr1te]

This is what I get from the console in cubeIDE. I have made many changes in the stm32f1x.cfg file
The changes include:
Changing from 0x1ba01477  to  0x2ba01477 and back in this line

#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0008 Section 26.6.3
      set _CPUTAPID 0x3ba00477
   } {
      # this is the SW-DP tap id not the jtag tap id
      set _CPUTAPID 0x20036410
   }
}

Changing this, expected ID should be 0
#swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0

I have tried adding this expression before the if statements

set CPUTAPID 0

and this expression

reset_config trst_only

This is the printout from the Console in cubeIDE. It is followed by the Could not verify the ST device statement. This printout does not change no matter what I change in the .cfg file. I get the feeling that the issue is elsewhere. The changes I make have no effect. 


Print starts:
Open On-Chip Debugger 0.11.0+dev-00438-ga75fc63 (2021-11-03-15:27)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J39S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.658746
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Error: BUG: can't assert SRST
Info : stlink_dap_op_connect(connect)
Error: BUG: can't assert SRST
Info : SWD DPIDR 0x2ba01477
Info : STM32F103T8Ux.cpu: Cortex-M3 r2p1 processor detected
Info : STM32F103T8Ux.cpu: target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32F103T8Ux.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : device id = 0x20036410
Info : flash size = 64kbytes
O.K.

O.K.:0xE00FFFD0

shutdown command invoked
Info : dropped 'gdb' connection
Print ends:


Is this my device ID?

Info : device id = 0x20036410

Any advice on how to continue is most welcome!!

Just a quick point out that openocd supports JTAG and SWD and the TAP_ID's are different there is a calc you can do to get one to the other but i cannot remember it, what are you using for the actual programming adapter? if it's a blue/black pill based device then it can support both BMP and CMSIS-DAP software's which work with gdb backends (via network too) , i found great success under cubeide and vscode/platformio debugging devices.


darkspr1te

[anda3243]

This is what I get from the console in cubeIDE. I have made many changes in the stm32f1x.cfg file
The changes include:
Changing from 0x1ba01477  to  0x2ba01477 and back in this line

#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0008 Section 26.6.3



Info : device id = 0x20036410
Info : flash size = 64kbytes
O.K.

O.K.:0xE00FFFD0

shutdown command invoked
Info : dropped 'gdb' connection
Print ends:

...................................
....................................

Is this my device ID?

Info : device id = 0x20036410

Any advice on how to continue is most welcome!!

Just a quick point out that openocd supports JTAG and SWD and the TAP_ID's are different there is a calc you can do to get one to the other but i cannot remember it, what are you using for the actual programming adapter? if it's a blue/black pill based device then it can support both BMP and CMSIS-DAP software's which work with gdb backends (via network too) , i found great success under cubeide and vscode/platformio debugging devices.


darkspr1te

I am using a ST-Link V2 programmer connected to the PA13 and PA14 pins.

It is a custom board with the STM32F103T8U6 mcu (fake one). This mcu is the little brother to the one used in bluepill boards (STM32F103C8T6).


/Andris

[pcprogrammer]

I should use openOCD right? As far as I read there is no chance to get this working with GDB server.

I use netbeans 8.2 with the GNU arm toolchain plus openOCD and a ST-link V2 clone to do debugging of these "STM" devices. It did work with the clone versions I got from Aliexpress. (CS32 type MCU's) So you should be able to do the debugging, but might need to switch to another IDE. Eclipse should be able to do it without the STM Cube stuff, but you have to research how to set it all up.

Netbeans 8.2 is old and no longer downloadable but I'm used to it and lets me do multiple environments like AVR, ARM, PHP, HTML and even remote Raspberry PI. Not sure if the latest version of Netbeans supports C/C++. Did not keep up with it.

Edit: The GNU toolchain includes the GDB server for debugging

[anda3243]

SOLVED

I think cubeIDE has some smart ways to detect fake chips. The workaround suggested above for the "bluepill" boards and the STM32F103C8T6 copies did not work for my smaller package STM32F103T8U6. There might be some other workaround that is different than for the bluepill board ones, that works for the smaller chip, but I could not figure it out. Or the chips that I got delivered could in some other way be recognized as fake by the cubeIDE, not only by the internal ID number.
Could later version of cubeIDE some sneaky new ways to detect fake chips?

I did the following;
Use cubeMX to configure the pins and generate code
I downloaded CrossStudio from Rowley. Have a 30 day trial now, will buy the license later.
Imported the output from cubeMX into Cross studio.
I needed to mess around a little with different support packages, but nothing too difficult, a couple of tries later we have BLINKY.

https://www.instagram.com/tv/Cc7KuLeFyOc/?utm_source=ig_web_copy_link

Thank you for suggestions of trying a different IDE!

[Doctorandus_P]

But what was the root cause of the problem?
Have you been able to verify the chip was fake?

[anda3243]

But what was the root cause of the problem?
Have you been able to verify the chip was fake?

With 80% likelihood the chip is fake. Its internal ID does not match the expected value.
The fix that works for the larger bluepil chip did not work for the smaller chip I use. Of course there is a chance that I have messed something up while implementing that fix, but I tried all variation of this above mentioned fix I could find.
Maybe there are some other measures that cubeIDE uses to validate that the chip is genuine that I am not aware of.

What I can say for sure is that with a different IDE it worked perfectly.

I have received a second batch of these boards, where the chip might be genuine. I will try these boards later.

[Doctorandus_P]

If the chip gives of the wrong ID, then the chance it's a real STM chip is much less then 20%.

What I can say for sure is that with a different IDE it worked perfectly.

I would not rely on that.
There are some 8 different clones of the STM23F103C8T8 and they have some differences which can be quite significant in a real project, but you will not see these differences and incompatibilities in a blinking led project.
LCSC has direct links to datasheets for most of them.

[BreakingOhmsLaw]

There are some 8 different clones of the STM23F103C8T8

Funny enough, some clones have actually fixed the errata from the original chip 
IIRC, the original has some particularly nasty issue with timers in conjunction with SPI.

[anda3243]

There are some 8 different clones of the STM23F103C8T8

Funny enough, some clones have actually fixed the errata from the original chip 
IIRC, the original has some particularly nasty issue with timers in conjunction with SPI.

I think one of those chips are CSK32F103C8T6. I think since they at least partly put their own name on it, it is a little better than other fakes. I will try to use this in the final product.

[Simon]

I have noticed that ST are putting rockets up their own assholes by fuelling the situation with chip hoarding due to the way they won't deal with people. You can't buy direct unless they are in stock and they won't tell you when they plan to make more. So if a distributor does not have any you are stuffed and it seems so are the distributors as they have none compared to the dealers that have now all got themselves listed on Octopart with 10'000's of parts to distributors 100's or 1000's. So what are the chances that the dealers are selling fakes or are they just setting up alerts for every STM32 chip and buying the lot as soon as they become available?

Back in September I went looking for a micro-controller I could start from scratch with and buy a sensible quantity of for the next two years, STM - no chance, even AVR's were flying off the shelves, I settled on a SAMC from microchip with 127kB of FLASH rather than the top 256kB as they were all gone anyway and pre-ordered 1'000 to be delivered in November with next manufacture stated as next November which now is May next year.

The idea of the STM32 cube setup is nice but are we just competing for fakes with the rest of the world only to find they won't work? and no, I don't want to use fakes even if they software can be tricked - not worth our reputation if there are problems.

[anda3243]

I dont know if you have Instagram and are able to see this link. This is how overseas chips often are obtained in China. Who know what those have been trough. I think China is hit not only by shortage, but also trade war. Some IT chips are worth gold. Also some STM chips.

[DavidAlfa]

I have a 7kg box like that
My company dumped a lot of outdated/expired parts (Yes, to comply ISO-something, parts have expire date) and I took it. Most is pretty old and useless, but I've found F-RAMs and other little interesting ICs.
Sadly the mcus are very old nothing interesting.

[Simon]

I have a 7kg box like that
My company dumped a lot of outdated/expired parts (Yes, to comply ISO-something, parts have expire date) and I took it. Most is pretty old and useless, but I've found F-RAMs and other little interesting ICs.
Sadly the mcus are very old nothing interesting.

So now you can make your fortune on ebay.