stlink server debugging doesn't work

[mrmyxc]

Hi, I'm trying to use the stlink server type and it looks like one of the commands sent is not understood by ST's GDB server.

Error when trying to debug

-target-select extended-remote localhost:50000 10-interpreter-exec console "monitor halt" 11-interpreter-exec console "monitor reset" 12-target-download 13-interpreter-exec console "monitor reset" 14-enable-pretty-printing -> 5^done GDB -> App: {"token":5,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}} -> =cmd-param-changed,param="language",value="c" GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"cmd-param-changed","output":[["param","language"],["value","c"]]}]} -> =cmd-param-changed,param="language",value="auto" GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"cmd-param-changed","output":[["param","language"],["value","auto"]]}]} -> 6^done GDB -> App: {"token":6,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}} -> ~"Output radix now set to decimal 16, hex 10, octal 20.\n" GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"console","content":"Output radix now set to decimal 16, hex 10, octal 20.\n"}]} Output radix now set to decimal 16, hex 10, octal 20. -> =cmd-param-changed,param="output-radix",value="16" GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"cmd-param-changed","output":[["param","output-radix"],["value","16"]]}]} -> 7^done GDB -> App: {"token":7,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}} -> ~"Input radix now set to decimal 10, hex a, octal 12.\n" GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"console","content":"Input radix now set to decimal 10, hex a, octal 12.\n"}]} Input radix now set to decimal 10, hex a, octal 12. -> 8^done GDB -> App: {"token":8,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}} -> =thread-group-started,id="i1",pid="42000" GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"thread-group-started","output":[["id","i1"],["pid","42000"]]}]} -> =thread-created,id="1",group-id="i1" GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"thread-created","output":[["id","1"],["group-id","i1"]]}]} -> ~"0x080039e4 in Reset_Handler ()\n" GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"console","content":"0x080039e4 in Reset_Handler ()\n"}]} 0x080039e4 in Reset_Handler () -> *stopped,frame={addr="0x080039e4",func="Reset_Handler",args=[],arch="armv7e-m"},thread-id="1",stopped-threads="all",core="0" GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"exec","asyncClass":"stopped","output":[["frame",[["addr","0x080039e4"],["func","Reset_Handler"],["args",[]],["arch","armv7e-m"]]],["thread-id","1"],["stopped-threads","all"],["core","0"]]}]} mi2.status = stopped Program stopped, probably due to a reset and/or halt issued by debugger -> 9^connected GDB -> App: {"token":9,"outOfBandRecord":[],"resultRecords":{"resultClass":"connected","results":[]}} -> &"Protocol error with Rcmd\n" GDB -> App: {"outOfBandRecord":[{"isStream":true,"type":"log","content":"Protocol error with Rcmd\n"}]} Protocol error with Rcmd -> 10^error,msg="Protocol error with Rcmd" GDB -> App: {"token":10,"outOfBandRecord":[],"resultRecords":{"resultClass":"error","results":[["msg","Protocol error with Rcmd"]]}}

The below is me manually trying to test it. monitor halt is fine when using openocd though.

Program received signal SIGINT, Interrupt. main () at core/src/main.c:88 88 while(1); (gdb) monitor reset halt STM32 Successfully completed reset operation (gdb) monitor halt Protocol error with Rcmd (gdb)

Using vscode 1.65.2 cortex-debug v1.2.2. (same result with pre-release v1.3.4) ST-LINK GDB server v5.5.0 STLINK fw ver: V2J36M26

I didn't see this raised and tbh I'm not very familiar with using gdb itself to debug applications so I thought I'd report it.

[haneefdm]

Thank you for reporting this. Basically, a monitor halt is failing. Failed at the starting blocks

This indicates a communication error between gdb and the 'ST-LINK GDB server'. We are not involved in their chatter and we don't even speak the language used between the two. I am thinking there may be a mismatch between the STLink server and the version of gdb -- hopefully, both came from what ST distributes and a matched set.

In the manual gdb mode, after a target extended-remote host:port, do a monitor help. Make sure you use the extended-remote as the protocol differs. I want to make sure halt is a valid command.

We used to use monitor reset halt ourselves but we get a warning from ST that is not valid. According to section 2.9, it is indeed invalid https://www.st.com/resource/en/user_manual/um2576-stm32cubeide-stlink-gdb-server-stmicroelectronics.pdf

Technically, we don't need a monitor halt because we use the -halt command-line option. This was all done by multiple people with experiments done as to what works at various times in history. But at the same time I have never seen a gdb-server not have a halt type command. ie, without doing a reset. I can understand halt and reset being two separate commands. Every gdb-server does the reset and halt a bit differently, btw.

Btw, I am using STLink GDB Server 6.0.0 (I got it from the STM32 IDE install).

% ./ST-LINK_gdbserver --version

./ST-LINK_gdbserver  version: 6.0.0

If changes need to be made on our end, I can make another pre-release. I don't want to change thing unnecessarily because we have very limited ways in which we can test.

[mrmyxc]

Alright thanks for responding. I'll try this out tomorrow and get back

[haneefdm]

I also made a pre-release this morning and it should work even the pre- 6.0.0 version of STLink server. Let me know if you need to reopen. Closing for now.