How to reset target chip?

[maxgerhardt]

From OpenOCD commands like monitor init and monitor reset halt are available to reset (and halt after reset) the chip. (docs).

When I connect to the GDB server opened by this script with avr-gdb (7.3.0) and try that, I however get

> monitor init
Target does not support this command.
>monitor reset
Target does not support this command.

with script output

INFO:root:Reading from address 0x00280A
bytearray(b'\x0c\x06')
0c06
<- $0c06#f9
INFO:root:No event
-> +$m80280a,2#2e
<- +
INFO:root:AVR running state False
80280a
2
80
INFO:root:Reading from address 0x00280A
bytearray(b'\x0c\x06')
0c06
<- $0c06#f9
INFO:root:No event
-> +
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
INFO:root:No event
-> $qRcmd,7265736574#37
<- +
INFO:root:AVR running state False
Rcmd,7265736574
<- $#00
INFO:root:No event
-> +
INFO:root:No event
-> $m80280a,2#2e
<- +
INFO:root:AVR running state False
80280a
2
80

How do I reset the target chip with this GDB server?

[stemnic]

This is again something that is just not implemented yet in the rsp server so as #11. Though thanks for sending the command flow, now I know what it needs to handle when I implement it :)

[stemnic]

After having a deeper look it seems like gdb target remote does not expect the target to reset itself while there is a connection in place. As you mentioned monitor reset looks like the overall accepted way of resetting a gdb server connected to a embedded device though that requires the gdb session to be initiated with target remote-extended. It should be easy enough to just implement handling for monitor reset then though I am not sure what more is expected from the rsp server when it is in a remote extended session compared to a normal one

[maxgerhardt]

I am not sure what more is expected from the rsp server when it is in a remote extended session compared to a normal one

In fact PlatformIO already uses target remote-extended with this script and debugging works there, normally, see bottom of #11 and here as for what PlatformIO does with GDB.

But I'm in no way a GDB server expert so I can't say for sure if it has more implications. 😅

[stemnic]

I am not sure what more is expected from the rsp server when it is in a remote extended session compared to a normal one

In fact PlatformIO already uses target remote-extended with this script and debugging works there, normally, see bottom of #11 and here as for what PlatformIO does with GDB.

Interesting, then it would not hurt to try :) The debugger interface with pyedbglib should at least have no problem resetting the device as long as the server understands what the gdb client wants. Could be that it works just fine since it is ignoring the commands it does not have a handle for it.

But I'm in no way a GDB server expert so I can't say for sure if it has more implications. 😅

Hehe, would not claim that either 😅 documentation for it is sometimes so lacking that I end up just connecting up gdb and see what commands the sessions sends.

[stemnic]

Note to self:
Docs extended mode and packets
Docs regarding restarting target in remote mode

• Confirm ! packet works as expected
• Implement R XX to preform target reset
• Figure out qRcmd packet parsing and make it able to handle monitor reset and monitor reset halt
• Investigate if extended mode expects the TCP connection to be reset or kept alive when target resets