ST-LINK: Could not verify ST device

[MSZ1]

When "ST-LINK: Could not verify ST device!" error appears and what the mentioned verification process consists of? Can I influence verification process in STM32CubeIDE and how?

I have STM32 MCU, which gives me "ST-LINK: Could not verify ST device!" in STM32CubeIDE whatever i do (trust me, i did a lot). ST-LINK Utility can connect to this MCU without any problem, so I wanted to ask for more information about the famous verification, which doesn't let me to debug the MCU. Thank you.

[Tesla DeLorean]

What STM32 part, specifically, are you trying to connect too?

OpenOCD has typically used the CPUTAPID to gate access to ST chips

[MSZ1]

STM32F103C8T6, BluePill. Tried change CPUTAPID in "STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_1.3.0.202002181050\resources\openocd\st_scripts\target\stm32f1x.cfg" from 0x1ba01477 to 0x2ba01477, but it doesn't work this time. Tried also switch to OCD debug and comment "reset_config srst_only srst_nogate connect_assert_srst" statement without success. So, verification must be more complex process.. probably. Chip has ST logo and correct name (no CS32F1...).

[Uwe Bonnes]

Does Stm32CubeProgrammer attach to the CPU. Try also connect under reset.

[MSZ1]

Connecting under reset stalls the process for a while and fails as usual. Tried holding the reset for various periods, didn't help. I used connecting under reset to program other mcus many times, so I don't think I did something wrong.

[waclawek.jan]

> Chip has ST logo and correct name (no CS32F1...).

Unfortunately, bluepills these days come often with counterfeited mcu, i.e. with one which has ST marking but the chip inside is not STM32.

https://www.eevblog.com/forum/microcontrollers/cheap-bluepill-very-likely-it-has-fake-stm32-right/

https://richis-lab.de/STM32.htm

[MSZ1]

Is there any way to read CPUTAPID from MCU with st-link v2? I know it's possible with J-Link, but st-link? Where is this value stored?

[Uwe Bonnes]

For the STM32 clone I have seen, the RomTable PIDR does not contain the designer 0x20 (STM) and Partno 0x410 but a generic arm 0x403 idicator for a M3 rom table.

Otherwise the core revision in AP IDR register is 2 while genuine parts only use revision 1. The Bl*ckm*g*c debugger in get gead now tell users about a possible non-genuine part.

[MSZ1]

I was searching for chips looking similar to mine and I'm pretty sure it's not genuine.

My problem was not about any different cputapid than this changed to 0x2ba01477, but generally debug process, when using ST-LINK (OpenOCD).

It throws an error:

"embedded:startup.tcl:24: Error: target requires -dap parameter instead of -chain-position!",

no matter if st-link is connected to pc. Tried it also on STM32F030K6T6, which works great with ST-LINK (ST-LINK GDB server) option and the result is the same, but it's for another topic I think.

This is short explanation of, "why I had problems even with changed cputapid?", but I think this value is all verification process and it's causing "Could not verify ST device" error.

I'm still curious if I can change CPUTAPID if I use Run -> Debug conf. -> Debugger -> Debug probe set for ST-LINK (ST-LINK GDB server).

[star_programmer]

Bro did you solve your problem? If you solved it can you explain because i have the same problem :(

[Tesla DeLorean]

Mostly this is to protect against counterfeit devices.

I've seen the ST-LINK DLL in Keil throw this on STM32G031 devices, but it may be reflective of an initial probing/capture of SWD connectivity. And if the MCU is in a cooperative state.

Perhaps make sure NRST is connected, and "Connect Under Reset" is used. Or the bus speed is dropped, especially for CM0(+) devices, which often work a lower speeds.

You've provided little actual context to understand your specific situation. Elaborate.