Why can't ST-LINK_gdbserver connect to my NUCLEO-H7S3L8?

[PhucXDoan]

All I'm looking for is to just somehow set up a GDB server for the NUCELO-H7S3L8 so I can do some debugging. My other board (NUCLEO-L476RG) worked fine using openocd, but my H7 has decided to siphon my precious humanity by being insanely difficult. I tried to use ST-LINK_gdbserver because I assume this is what CubeIDE uses under the hood. In fact, I can create a basic blinking program for the H7, compile it, upload it, and debug it all in CubeIDE just fine, but this is just not my preferred style of development. But CubeIDE apparently has some sort of magical incantation that my lowly existence doesn't know about in order to get ST-LINK_gdbserver to actually connect to the H7 target.

> C:\ST\STM32CubeIDE_1.16.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.1.400.202404281720\tools\bin>ST-LINK_gdbserver.exe -cp C:\ST\STM32CubeIDE_1.15.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.201.202404072231\tools\bin -d

STMicroelectronics ST-LINK GDB server. Version 7.8.0
Copyright (c) 2024, STMicroelectronics. All rights reserved.

Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 31
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled

COM frequency = 24000 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 8000 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 3300 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 1000 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 200 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 50 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 5 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
Target unknown error 32

Error in initializing ST-LINK device.
Reason: Unknown. Please check power and cabling to target.

 This is obviously not a connection issue, because once again: it works in CubeIDE.

Am I stuck in purgatory? What's going on? Again, all I want to do is just set up a debugging session; I frankly don't even care about ST-LINK_gdbserver...

[MM..1]

Try use config file and start over bat

@Echo off
cmd /K "ST-LINK_gdbserver.exe -c config.txt || echo GDB server exited"

too check if STLink isnt used by other...

[PhucXDoan]

I'm not sure how the config.txt helps, as all it does is pass the -e, -f, -p, -r, -d, flags. The -cp flag I had to modify, which suggests that the config.txt (the one I found in same folder as the batch file) is supposed to be something else? But I searched the C:\ST for other config.txts and found nothing else.

###############################################################
#### ST-LINK_gdbserver - Sample Configuration File
#### Each Line Contains one argument
#### Comment lines begin with #
####
#### Use option -c <config-file> to start with config file
####  ST-LINK_gdbserver -c config.txt
####
#### Options without SWV
####  ST-LINK_gdbserver.exe -e -d -cp C:/ST/STM32CubeIDE_1.3.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.3.0.202002181050/tools/bin
####
#### Options with SWV, Core clock 168MHz, SWO Clock 1 MHz
####  ST-LINK_gdbserver.exe -e -d -z 61235 -a 168000000 -b 168 -cp C:/ST/STM32CubeIDE_1.3.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.3.0.202002181050/tools/bin
####
#### Get option information
####  ST-LINK_gdbserver.exe -h
####
#### The ST-LINK_gdbserver manual contains detailed information
####  about options and program usage.
####
###############################################################

###############################################################
#  -e                 : Enables persistant mode
###############################################################
-e

###############################################################
#  -f <Log-File>      : Name of log file. Please make sure
#                       that directory not is write protected.
###############################################################
-f debug.log

###############################################################
#  -l <Log-Level>     : Logging level between 0 & 31
#          0            Disables logging
#          >=1          Enables logging of error messages
#          >=2          Adds warning messages
#          >=4          Adds communication specific messages
#          >=8          Adds all information messages
#          >=16         Adds all HW specific messages
###############################################################
#-l 31

###############################################################
#  -p <Port-Number>   : TCP-Listen Port-Number.
###############################################################
-p 61234

###############################################################
#  -v                 : Enables verbose mode
###############################################################
#-v

###############################################################
#  -r <delay-sec>     : Maximum Delay in status refresh
###############################################################
-r 15

###############################################################
#  -d                 : Enables SWD mode
###############################################################
-d

###############################################################
#  -t                 : Shared mode using ST-LINK server
###############################################################
#-t

###############################################################
#  -cp <path>         : Path to STM32CubeProgrammer
#                       Modify to correct path
#                       for STM32_Programmer_CLI executable
###############################################################
# Originally: -cp <path to directory containing STM32_Programmer_CLI executable>
-cp C:\ST\STM32CubeIDE_1.15.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.201.202404072231\tools\bin

The ST-LINK is definitely isn't being used by another process or anything, since a simple unplug and replug would've resolved that issue.

[Uwe Bonnes]

Does your debugger hardware use a recent firmware? H7RS has only been introduced recently.

[PhucXDoan · Accepted solution]

Yes, I've updated the ST-LINK firmware if that's what you're referring to, but that also wouldn't be the issue since debugging already works in STM32CubeIDE.

Regardless, I've finally managed to figure out how to do what I wanted to do though (that is, setting up a GDB server).

Since every single online forum I've combed through was always so *** vague, I'll like to be a saint to those who are in the same boat as I was:

First, go into the IDE with a basic project that has proven to be able to program the board and debug. Then look into the Debug Configuration settings, which is in the dropdown menu of the debug button.

Then find the project and look in the Debugger tab, in here is where CubeIDE configures the connection of the debugger. One of the things you can do in this tab is Show Command Line, which tells you "exactly" what CubeIDE is doing.

Now I put "exactly" in quotes because the command for calling ST-LINK_gdbserver worked only partially. The program recognized the ST-LINK and the target device, but no complete connection was established; a busy wait happens indefinitely. So CubeIDE is still doing something additional that I don't know about.

I have no love for ST-LINK_gdbserver at this point, though, so what I then did next was change the debug probe to ST-LINK (OpenOCD) and once again copy the command line options, which was this for me:

/home/phucxdoan/st/stm32cubeide_1.16.0/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.linux64_2.3.200.202404091248/tools/bin/openocd "-f" "TMP_Boot Debug.cfg" "-s" "/home/phucxdoan/STM32CubeIDE/workspace_1.16.0/TMP/Boot" "-s" "/home/phucxdoan/st/stm32cubeide_1.16.0/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.2.100.202406131243/resources/openocd/st_scripts" "-s" "/home/phucxdoan/st/stm32cubeide_1.16.0/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.1.200.202405171325/resources/openocd/st_scripts" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444"

 This works in connecting and setting up a GDB server at :3333.

[PhucXDoan]

Ok, I spoke too soon I guess, because for some reason, openocd HAS to reset the target. This means I can't just flash the binary and then attach the debugger on later if an error condition occurs. I'd likely have to attach the debugger at the start (after I finished flashing) and then continue it, or dig around deep into the openocd configuration files to figure out what the hell to do to get openocd to just not reset the target. It's an absolutely time waster given the fact that I can already create a debugging session just fine on my other L4 board, but this *** ST-LINK V3 is just raising hell.

So I looked back at the command line options for ST-LINK_gdbserver according to ST32CubeIDE...

/home/phucxdoan/st/stm32cubeide_1.16.0/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.1.400.202404281720/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/phucxdoan/st/stm32cubeide_1.16.0/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_2.1.400.202404281720/tools/bin -m 1 -g

... and as stated, running this (at least on my machine) just results in a busy wait where the debugger never actually connects. I expect STM32CubeIDE to be executing this same command, but somehow it just isn't facing the same issue.

As it turns out, if you remove the "-l 1" argument:

/home/phucxdoan/st/stm32cubeide_1.16.0/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.1.400.202404281720/tools/bin/ST-LINK_gdbserver -p 61234 -d -s -cp /home/phucxdoan/st/stm32cubeide_1.16.0/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_2.1.400.202404281720/tools/bin -m 1 -g

IT NOW WORKS. I guess ST-LINK_gdbserver was having issues with logging of all things? Ugh. Weekend wasted.