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.