How to deal wirh : Could not verify ST device! ?

PZwar · ‎2019-10-14

Dear all,

Could not verify ST device!

This error popped up suddenly and blocks any progress. I took an older computer and had the same error again.

Therefore, I suspected a hardware failure and ordered new adapters and processor boards, but I kept having the same error again.

I have upgraded the STM32CubeIDE, the st-link drivers (dpinst_amd64.exe) and st-stlink-server(st-stlink-server.1.1.1-3.msi).

The st_link v2 adapter have been upgraded with the latest firmware.

Using STM32 Link Utility, I was able to program, verify and run blink applications.

I am using BluePills (STM32F103C8) with chinese adapters on a 64 bit Windows 10 machine.

Please find below the output produced when starting debugging in STM2CubeIDE using the GDB server in SWD mode.

I also selected the OPENOCD debugger, but it also failed, though in a different way.(see below)

Does anyone have a suggestion how to proceed on this?

Cheers, Paul

..........................ST-LINK GDB server.....................

STMicroelectronics ST-LINK GDB server. Version 5.2.3

Starting server with the following options:

Persistent Mode : Disabled

LogFile Name : C:\Users\Paul_2\Documents\STM32\Workspace\test\Debug\st-link_gdbserver_log.txt

Logging Level : 31

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Enabled

SWD Debug : Enabled

Hardware watchpoint supported by the target

SWD frequency = 4000 kHz

ST-LINK Firmware version : V2J31S7

Device ID: 0x410

PC: 0xc6640804

ST-LINK device status: HALT_MODE

ST-LINK detects target voltage = 3.17 V

Vendor = 0x55

Error in initializing ST-LINK device.

Reason: ST-LINK: Could not verify ST device! Abort connection.

......................OPENOCD.........................................

Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-04-23-20:37)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

srst_only separate srst_nogate srst_open_drain connect_assert_srst

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 8000 kHz

adapter_nsrst_delay: 100

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : clock speed 8000 kHz

Info : STLINK v2 JTAG v31 API v2 SWIM v7 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.166882

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Info : Stlink adapter speed set to 4000 kHz

Warn : UNEXPECTED idcode: 0x2ba01477

Error: expected 1 of 1: 0x1ba01477

in procedure 'init'

in procedure 'ocd_bouncer'

Kraal · ‎2019-10-14

Hi !

I am not very fluent in SWD, but the verbose output from Open OCD helps to identify the issue : the ID read by both tools differs from what is expected. Meaning that the error is the same in both cases.

Your device under test reads back 0x2ba01477 while the tools expect 0x1ba01477. I don't think it can be an electrical problem. Since you are using a bluepill, maybe the microcontroller is a counterfeit product. You should ST about this, perhaps with a picture of the uC.

PZwar · ‎2019-10-17

Could not verify ST device!

Thank you so much, Kraal!

I inspected the looks of the chip and found it quite different from the ones I used before.

The text was not engraved but printed in a sloppy way. I think that your suggestion of a counterfeit is right.

I tried to make these counterfeits working under STM32CUBEIDE and OpenOCD.

Therefore, I adapted the st_scripts/target/stm32f1x.cfg file by replacing the 0x1ba01477 by 0x2ba01477.

I also added a line:

reset_config trst_only

This gives a error message:

Error: BUG: can't assert SRST

Neverthless, I could load and debug my code.

Kraal · ‎2019-10-17

Hi Paul,

I'm glad you find a way to use your dev board even if the device ID is not correct.

I would add that for test or learning purpose it is OKish to use the bluepill with the strange part as it is, but for anything that goes into production you should always use real product.

Best regards,

Kraal

SWadi.1 · ‎2020-03-16

Hi PZwar,

I have the same problem.

However I am unable to locate the "st_scripts/target/stm32f1x.cfg" file or folder on windows 10.

Using STM32CUBEIDE and OpenOCD.

Thanks & regards

=====================Debug log =========================================

Open On-Chip Debugger 0.10.0+dev-01193-g5ce997d (2020-02-20-10:57)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

srst_only separate srst_nogate srst_open_drain connect_assert_srst

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 4000 kHz

adapter_nsrst_delay: 100

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : clock speed 4000 kHz

Info : connected to stlink-server

Info : stlink-server API v1, version 1.3.0

Info : STLINK V2J36S7 (API v2) VID:PID 0483:3748

Info : using stlink api v2

Info : Target voltage: 3.180552

Info : SRST line asserted

Warn : UNEXPECTED idcode: 0x2ba01477

Error: expected 1 of 1: 0x1ba01477

PZwar · ‎2020-03-16

Dear SWadi.1,
Since the problem occurred I have upgraded tp version 1.2.0 of
stm32Cubeide.
There are two versions of the file:
C:\ST\STM32CubeIDE_1.2.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_1.3.0.202002181050\resources\openocd\st_scripts\target\stm32f1x.cfg
and
C:\ST\STM32CubeIDE_1.2.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug_1.2.0.201912201802\resources\openocd\st_scripts\target\stm32f1x.cfg
I modified the *first* file.
Success!
PZwar
Op 16/03/2020 om 21:44 schreef ST Community:

SWadi.1 · ‎2020-03-17

Hey PZwar,

Thanks found it!! 🙂

I am using STM32CubeIDE_1.3.0, found /stm32f1x.cfg --> path below

"C:\ST\STM32CubeIDE_1.3.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_1.3.0.202002181050\resources\openocd\st_scripts\target"

Got the STM32CubeIDE to download and debug code after doing the chip id changes.

Thanks

S.Ma · ‎2020-03-17

Hmm the MSB bits of the ID Code register are just a version number so 2 means newer than 1.. ?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100230_0002_00_en/Chunk424975896.html

JElli.1 · ‎2020-05-15

If you replace 0x1ba01477 with 0x2ba01477 in stm32f1x.cfg, then it will work for the clone but not for the genuine STM32…

Instead do the following: >>

In the stm32f1x.cfg - file, find the command line (around line 62) starting with : swj_newdap
At the end of this command line you will see : -expected-id $_CPUTAPID
Simply change it to: -expected-id 0

The zero tells OpenOCD to ignore id numbers, which means all clones or genuine MCUs will work.

Save the changes. Now your flash and debug should work.

Information Source: http://openocd.org/doc/html/TAP-Declaration.html#TAP-Declaration-Commands

SWadi.1 · ‎2020-05-17

hey JElli.1,

Thanks for the new info..

I tried it and it works for the clone. 😎 👍

But my order for the original is still not delivered thanks to COVID-19.. shall update once i test both.

regards