STM32F407ZET6 Could not verify ST Device

[Neolithic]

Hi All,

I have a setup where I bought a STM32F407ZET6 dev board from AliExpress and have been using for almost 6 years using STM32Cube IDE. It was only until i updated my IDE from 1.6 to 1.14 when it started saying that "Could not verify ST Device! Please verify that the latest version of gdb-server is used for the connection". my openocd is remotely running on Raspiberry pi where it uses the bitbanging driver to drive the GPIOs for establishing an SWD connection. 

This same question has been addressed in several other threads in the context of bluepill (https://community.st.com/t5/stm32-mcus-boards-and-hardware/how-to-deal-wirh-could-not-verify-st-device/td-p/234230/page/2).

On the OpenOCD side, i am getting this error:

I tried changing the -expected-id $_CPUTAPID to different values suggested in different posts (including 0), but nothing works. Most of the forums talk about this issue in the context of Bluepill; however this is STM32F407 based board.

Can anyone please help me with this problem. I will appreciate the help. Thanks.

Regards,

Junaid

[Neolithic]

Unfortunately not. The ST's own tech support suggested me to use cube ide 1.6.0 since this issue seems to be weird as the chip is not counterfeit.

But, if you just use generic gdb debugging you can still do it with latest versions. 

[splasher]

Hi, thanks for your replay.

I'm using Version 1.6.0 now, but still facing issues.

If I change to OpenOCD I can debug - but not with GDB server.
Is this a different issue?

[Neolithic]

Yes, this is a different issue. You need to check your gdb settings. I would suggest you to keep using OpenOCD if that works.

[shuocao]

Hello,

I am not having the exact setup as of yours, but basically I am trying to debug my stm32f373 MCU, which is bought from mouser, with official stlinkv3 bought from ST and connected to raspberry pi as remote. At first I also had the problem, that STM32CubeIDE displays like "Cannot verify ST device, please check if the latest gdb server is used". Then I just copy the config file which is generated automatically by cubeide in the project to raspi, and the openocd script folder in stm32cubeide installation also to raspi and specify the search path for openocd with "-s" to the script folder just copied. And now it works, i didn't dig into the problem, but basically the interface/target script shipped with openocd are not the same as ST composes, maybe ST needs more functions for openocd gdb server configuration.

Every time I change the debug configuration in stm32cubeide, i have to copy the config file to raspi, e.g. when I add swv later on.

Just for someone who might have the similar problem as mine.

[Neolithic]

Hi, Thank you for sharing your experience. This is very valuable. I will definitely try this and if it works for me too then I will accept your solution. And I agree, i also think that ST needs to add a bit more effort into supporting their SoCs in OpenOCD.

[Neolithic]

Can you please, for reference, mention here the paths of the scripts from where to copy and which directories to past them for ease of users.?

[shuocao]

Sure, the openocd scripts from ST could be found at:

C:\ST\STM32CubeIDE_1.7.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_2.0.400.202211031408\resources\openocd

My installation is 1.11.2

And config file generated by cubeide is in project folder like project.cfg

I copy the st_scripts and project.cfg to raspi, for example in Document, then just run the openocd with the config file:

sudo openocd -f project.cfg -s "st_scripts" -c "bindto 0.0.0.0" -c "init"

I need sudo since I didn't add udev rules for stlinkv3

[Neolithic]

Thanks for explaining. I am using Raspberry Pi bit bang driver. So far I have been using GDB-Hardware debugging configuration and that works seamlessly without any of the "Could not verify..." Issues.

[Javier1]

i already did this in 2021 https://community.st.com/t5/stm32-mcus-products/openocd-not-reseting-my-chip/td-p/192537

Great, they broke something with cubeIDE updates AGAIN

Using CUBEIDE 1.16.0 on my windows PC
and openocd 0.12.0 in a raspi3
im trying to flash an AUTENTIC stm32G474 nucleo trouhg a raspi3 and im having the same issue.
I guess i have to try ST-Link GDB instead of OPENOCD they dont provide ARM64 compiled STLINK GDB.

[raspi] my openocd.cfg is as follows

source [find interface/stlink-v2.cfg]
transport select hla_swd
set WORKAREASEIZE 0x2000
source [find target/stm32g4x.cfg]
reset_config srst_only srst_nogate
adapter speed 4000
bindto 0.0.0.0

 

[raspi] openocd starts with 

sudo openocd -f openocd.cfg -d3

[PC] and when

[raspi] the verbose output spits:
[...]

Debug: 370 60153 gdb_server.c:390 gdb_log_incoming_packet(): [stm32g4x.cpu] received packet: qSymbol::
Debug: 371 60153 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32g4x.cpu] sending packet: $OK#9a
Debug: 372 60160 gdb_server.c:390 gdb_log_incoming_packet(): [stm32g4x.cpu] received packet: qXfer:threads:read::0,1000
Debug: 373 60160 gdb_server.c:403 gdb_log_outgoing_packet(): [stm32g4x.cpu] sending packet: $<binary-data-44-bytes>#02
Debug: 374 60164 gdb_server.c:390 gdb_log_incoming_packet(): [stm32g4x.cpu] received packet: qRcmd,5265616441504578203078302030784638
Debug: 375 60165 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32g4x.cpu] sending packet: $O696e76616c696420636f6d6d616e64206e616d6520225265616441504578220a#0f
Debug: 376 60165 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32g4x.cpu] sending packet: $E01#a6
Debug: 377 60185 gdb_server.c:390 gdb_log_incoming_packet(): [stm32g4x.cpu] received packet: D
Debug: 378 60185 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32g4x.cpu] sending packet: $OK#9a
Debug: 379 60190 gdb_server.c:228 gdb_get_char_inner(): GDB connection closed by the remote client
Debug: 380 60190 gdb_server.c:1112 gdb_connection_closed(): GDB Close, Target: stm32g4x.cpu, state: halted, gdb_actual_connections=0
Debug: 381 60190 target.c:1843 target_call_event_callbacks(): target event 8 (gdb-end) for core stm32g4x.cpu
Debug: 382 60190 target.c:1843 target_call_event_callbacks(): target event 23 (gdb-detach) for core stm32g4x.cpu
Info : 383 60190 server.c:574 server_loop(): dropped 'gdb' connection

[Neolithic]

I have been, since then, using GDB Hardware debugging tab to create debug session in STM32 Cube IDE and that works without any issues. I would suggest doing that.