Failed to start GDB server Error in initialising ST-Link device

[ADabl.1]

Hello folks,

I am new to STM32 and have been using it (STM32H7A3ZIQ) for a while, everything was fine with download and debugging codes until a week ago when STM32CubeIDE suddenly has stopped launching the debug session. An error msg -failed to start GDB server (see attached) pops out whenever I want to debug codes, I have been trying to resolve this very problem for the past week by following other people's solutions on Youtube, but all my attempts were in vain.

In addition, I installed different ST-Link programs provided by ST such that ST-Link server (Utility), STSW 004, 007, and 009. But even by doing so, I couldn't resolve this matter and no device found remains.

NB:

• Even after having updated my device (V3.J8.M3) by using ST-Link 007, STM32CubeIDE doesn't recognise it at all (no device found on target).
• ST-Link utility also cannot connect to the target

I hope someone could help me to get back coding.

I look forward to hearing your expert thoughts on how to resolve it.

BR,

AD

[moatjon]

Hey AD,

Are you using a Nucleo board? If so, are the headers/jumpers on the Nucleo fitted correctly? The error message suggests that the ST-Link itself can be detected, but that the target itself is not found. Perhaps you can use the multimeter to check if both the ST-Link and the target chip are supplied with a proper VCC.

You mention you have used different ST-Link programs, have you also tried STM32CubeProgrammer? If not, you can try updating your ST-Link firmware through STM32CubeProgrammer. If STM32CubeProgrammer does detect your target chip, you can select the flashable binary output of your build folder and flash the chip manually through STM32CubeProgrammer.

I have had situations where STM32CubeIde did not detect my chip, while STM32CubeProgrammer did. If that's the case, a system restart usually solved the problem for me. You can also try using OpenOCD (Run>Debug Configurations>"Debugger" tab>Debug Probe).

I hope this helps.

Kind regards,

moatjon

[ADabl.1]

Hi Moatjon,

Thanks for replying!

Yes indeed, I am using Nucleo-board. The first thing I certainly did was inspect jumpers ( JP4 set to VDD, JP5 set to VDD 3.3 v, and JP2 set to STLink). Once the device is connected LED5 lights on.

Have a look at Image5 -STM32CubePro, the device is recognised only by its serial number, target voltage, and firmware version but when clicking on CONNECT a msg pops out saying that no STM32 target was found. (of course, one can realise that there is no target info, but why? I frankly have no clue) and I have found it a bit odd that only the serial number is detected.

*U mentioned the selection of the flashable binary output, how can I manage to do it... I couldn't find such a feature anywhere.

** On OpenOCD... image6 can support u with the configuration run.

hope this walks you through my problem.

BR,

AD

[ADabl.1]

Image5

[moatjon]

The detected firmware version and serial number relate to the ST-Link on the board, not the chip you're trying to program. LED5 lighting up is a good sign. Have you tried lowering the SWD frequency? You can also increase the verbosity level of STM32CubeProgrammer, that might give us some more information to work with.

Regarding the "manual" flashing: once you build your project in STM32CubeIde, or any toolchain really, you end up with a binary file. This binary file is located in your <project>/Debug folder, and you can select this file in STM32CubeProgrammer once you have succesfully connected to your target. As long as STM32CubeProgrammer can't connect to your target, it won't be of much use.

I also added an image showing how to select OpenOCD, although I don't think that will solve your issue at this moment.

Do you have a logic analyzer available? If so, you can check whether the SWD signal physically reaches your chip properly.

Kind regards and good luck,

moatjon

[ADabl.1]

Yes indeed, I've tried to change the SWD, but no response. Also, after having selected the debug probe as OpenOCD there is no response, and the main issue remains.

Is it possible that the debug chip was damaged because of smth wrong I did, especially, after having changed the CLK configurations?

[moatjon]

Unlikely but possible. I think it's one of two things:

1. (probably) We're missing something obvious.
2. You might have zapped (ESD) your microcontroller.

Can you replicate the issue with a different Nucleo board? Or do you have a different STM32 target chip laying around?

If so, you might be able to find out if the issue if with your ST-Link or your target chip.

[ADabl.1]

Hey Moatjon,

I unfortunately couldn't figure out where the problem is, so the best thing is that I am going to replace it with another new one. My guess is that the chip itself has been damaged, But I don't know-how.

Thanks anyway for your response.

BR,

AD

[JDIVO.1]

For those facing the error, but on different boards : it might be a problem with trustzone enabled.

You can look at the option byte TZEN in CubeProgrammer to check if trustzone is enabled or not.

The Getting started pdf guide of the package explains in the FAQ how you can disable trustzone.

[Pmartine92]

I have the same problem.the solution is to use STM32Programmer.to detect it you put the Shared tab on Enable.once that , you hold down the reset , and once it is trying to connect you release it.so you get it to connect.to finish , you delete the flash, and ready.
I have the same problem, what happens is that I don't know how to solve it, every time I load the program, it loads fine, the PCB works, but the GDB stops detecting it.