GDB z1 returns OK but FPB hardware breakpoint remains armed after disconnect

What happened

pyOCD acknowledges removal of a hardware breakpoint with an RSP OK, but the corresponding FPB comparator can remain programmed when GDB disconnects without resuming the target.

In the reproduced session, GDB/Cortex-Debug performed this shutdown sequence after the target stopped at a hardware breakpoint:

GDB -> pyOCD: z1,<breakpoint-address>,2
pyOCD -> GDB: OK

break-delete       -> ^done
target-disconnect  -> ^done
gdb-exit           -> ^exit

pyOCD did not exit on its own after the disconnect. The frontend then terminated the managed gdbserver process with SIGTERM.

After the session ended, the target still contained the old comparator:

FP_CTRL  = 0x10000081
FP_COMP0 = 0x08000805
FP_COMP1..7 = 0
DFSR     = 0x00000002
DEMCR    = 0x01000400
DHCSR    = 0x00030003

After a hardware reset using the wired NRST signal and a wait of approximately 1.8 seconds, the old breakpoint was hit again:

FP_COMP0 = 0x08000805
FP_COMP1..7 = 0
DFSR     = 0x00000002
DHCSR    = 0x00030003
PC       = 0x08000804

What I expected

Once pyOCD replies OK to the z1 removal request, the hardware breakpoint removal should be committed to the target. At minimum, any pending breakpoint removals should be flushed during disconnect or session cleanup.

After the debug session ends, no FPB comparator from that session should remain enabled, and hardware NRST should not cause the target to stop again at the old breakpoint address.

Steps to reproduce

1. Start a pyOCD gdbserver attach session using a CMSIS-DAP SWD probe.
2. Set a hardware breakpoint in flash and continue until it is hit.
3. Delete the breakpoint through GDB.
4. Disconnect from the target and exit GDB without resuming the target. In this test, selecting Stop in Cortex-Debug generated break-delete, target-disconnect, and gdb-exit.
5. Allow the frontend to terminate pyOCD if the gdbserver does not exit naturally.
6. Assert hardware NRST.
7. Observe that the target stops again at the deleted breakpoint and that the old FP_COMP value remains enabled.

Additional context

• OS: Windows 11
• pyOCD: 0.45.1
• Target: STM32C552CCU6 / Cortex-M33
• Probe: CMSIS-DAP over SWD; serial number intentionally omitted
• Session type: attach
• Cortex-Debug: 1.13.0-pre9
• Arm GNU GDB: GDB 14.2.90.20240526-git

The observed behavior is consistent with breakpoint removal being recorded as pending and the physical FPB update being deferred until a later run/resume operation. This shutdown path does not resume the target after z1, so that later update does not occur.

The Cortex-Debug maintainer reviewed the shutdown trace and concluded that pyOCD should complete the breakpoint deletion and exit after disconnect:

• https://github.com/Marus/cortex-debug/issues/1244
• https://github.com/Marus/cortex-debug/issues/1244#issuecomment-5067649121

Related but not identical: #1531 discusses IDE termination preventing normal cleanup and DAP disconnect, but does not cover an acknowledged z1 removal leaving an FPB comparator active.

I can provide a longer sanitized pyOCD/GDB trace or run a CLI-only control test if a specific command sequence or logging configuration is preferred.

Start with pyOCD's gdbserver handling of the RSP z1 removal request and disconnect cleanup. Reproduce the reported sequence: delete a hardware breakpoint while stopped, disconnect without resuming, then reset the target. Done means the FPB comparator is no longer enabled after cleanup and the gdbserver exits without leaving the deleted breakpoint active.