[Question] Restart not working: 'monitor reset hardware' returns 'Reply contains invalid hex digit 83'

Hi,

I think this is really a request for support rather than a potential bug so don’t hesitate to close this thread if it does not belong here.

I’m trying to get the restart/reset (not sure which one I should use to be honest) button working. What I want to do is to perform a device reset and re-run my program until main without flashing it again.

I have experience using gdb on the command line but VSCode and the Cortex Debug extension are fairly new to me.

My environment is the following:

• STM32F7508-DK with embedded STL-LINK v2.1 probe
• ST-LINK_gdbserver.exe version: 5.9.1
• GNU gdb (GNU Arm Embedded Toolchain 10-2020-q4-major)

The default restart command doesn’t work for me, I’m getting an “Unknown reset option” in the debug console. Which makes sense because the default reset command is “monitor reset halt” and it is not mentioned in the user manual for my server (§2.9)

So, I tried using the overrideRestartCommands parameter to set my own commands. Using GDB from the command line, I can perform the reset with the following commands (having previously set a breakpoint to main):

monitor reset hardware
j handleReset

Where handleReset is the entryPoint of my program (@0x08000000). This works just fine as long as I’m doing it manually, outside of VSCode.

So I wrote the following in my launch config:

"overrideRestartCommands": [
	"interrupt",
	"monitor reset hardware",
	"j handleReset"
]

But when I click the restart button, I get the following:

48-exec-interrupt
GDB -> App: {"token":48,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"console","content":"\nProgram"}]}

Program
GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"console","content":" received signal SIGINT, Interrupt.\n"}]}
 received signal SIGINT, Interrupt.
GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"console","content":"main () at /home/lutrampal/git/stm32-event-hal/src/example.cpp:77\n"}]}
main () at /home/lutrampal/git/stm32-event-hal/src/example.cpp:77
GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"console","content":"77\t        while (true) {}\n"}]}
77	        while (true) {}
GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"exec","asyncClass":"stopped","output":[["reason","signal-received"],["signal-name","SIGINT"],["signal-meaning","Interrupt"],["frame",[["addr","0x90008876"],["func","main"],["args",[]],["file","/home/lutrampal/git/stm32-event-hal/src/example.cpp"],["fullname","/home/lutrampal/git/stm32-event-hal/src/example.cpp"],["line","77"],["arch","armv7e-m"]]],["thread-id","1"],["stopped-threads","all"],["core","0"]]}]}
49-interpreter-exec console "interrupt"
GDB -> App: {"token":49,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
50-interpreter-exec console "monitor reset hardware"
GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"log","content":"Reply contains invalid hex digit 83\n"}]}
Reply contains invalid hex digit 83
GDB -> App: {"token":50,"outOfBandRecord":[],"resultRecords":{"resultClass":"error","results":[["msg","Reply contains invalid hex digit 83"]]}}

My whole launch configuration is the following:

{
    "name": "Cortex Debug",
    "cwd": "${workspaceRoot}",
    "executable": "./build/example.elf",
    "request": "launch",
    "type": "cortex-debug",
    "servertype": "stlink",
    "stm32cubeprogrammer": "${env:CUBE_PROGRAMMER_BIN_DIR}",
    "serverpath": "${env:STLINK_GDB_SERVER}",
    "serverArgs": [
        "-l", "31", "-v", "-s", "-k", "-el", "${env:STM32_EXT_LOADER}"
    ],
    "overrideGDBServerStartedRegex": "Waiting for connection on port.*",
    "gdbPath": "${env:GDB}",
    "svdFile": "${env:STM32_SVD_FILE}",
    "overrideLaunchCommands": [
        "load",
        "tb handleError"
    ],
    "runToMain": true,
    "preLaunchTask": "Build",
    "demangle": true,
    "showDevDebugOutput": true,
    "overrideRestartCommands": [
        "interrupt",
        "monitor reset hardware",
        "j handleReset"
    ]
}

It works fine for flashing and launching but I had to tinker a bit to get it working. So don’t hesitate to tell me if some things look weird in it…

I guess I must be doing something wrong, but I was unable to find my error. Could someone point me to right direction?

Thanks, Lucas

[haneefdm]

Unless I can reproduce the problem, there is nothing more I can do. All our testing is with V3 and it may very well be an issue between the ST gdb-server and the probe HW.

I will be fixing the monitor reset halt problem in the next release. Already fixed in my branch.

[lutrampal]

I understand, thank you for trying anyway.