[Bug]: Debug is not always turned off on disconnect with pyOCD

[jreineckearm]

Summary

As the title says

Description

Embedded debuggers often turn off the debug logic in the target system on disconnect. For Cortex-M CPUs, this sets the target system running again.

With pyOCD, this doesn't always happen. Which leaves the target system in debug halt until manually resetting or power-cycling the debugged board.
This can be confusing for users migrating over to this solution. It gives the impression that the target application is broken.

We should consider to make this behavior optional for pyOCD. Or at least to prepare it so that we can easily add an option in future. There could be reasons for keeping the CPU in debug halt in future use cases where for example a debugger prepares the target and brings it into the right state before another tool is supposed to take over (maybe for secure debug authentication).

Steps to Reproduce

1. Connect and disconnect from a board.
2. If you for example try with a Blinky example, LEDs won't continue blinking as expected after disconnect.

Expected Behavior

Debug logic is turned off on final disconnect. And LED start blinking as expected for a Blinky-like example.

Additional Information

No response

[jreineckearm]

@RobertRostohar, could you please set a fix version once you got a feeling for the involved effort?

[RobertRostohar]

The problem is related to how and when the GDB server (i.e. pyOCD) is killed. PyOCD will already disconnect from the target on GDB shutdown or detach.

When the debugger is launched the GDB server process is created by the GDB adapter extension and when debug is stopped the GDB server process is killed almost immediately. This results in the GDB server not having enough time to do a proper clean-up (including disconnecting from the target).

GDB server could catch the SIGTERM signal and ensure that the necessary clean-up is done before being terminated. Unfortunately, it seems that this signal cannot be caught on Windows.

We might introduce some delay before the GDB server is killed.

[jreineckearm]

More insights from previous work on CDT GDB adapter process managment:

• GDB server is forcefully terminated by GDB adapter on disconnect.
• Disconnect cleanly disconnects GDB. But even if GDB server shuts down based on configured behavior, the adapter may terminate the server too early. It doesn't wait at all.
• CDT GDB Adapter has automaticallyKillServer setting which is true by default.

Adapter already isn't fully compliant with MS DAP spec in this area. Hence, will go for a quick solution which is to add a server-kill-delay to give the backend time to shut down cleanly first. That in combination with automaticallyKillServer should be sufficient for most of our use cases.
Graceful shutdown is normally only attempted by MS DAP terminate request. Which is currently not supported, and might have to become part of solution.

[jreineckearm]

eclipse-cdt-cloud/cdt-gdb-adapter#398