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

[CaFeZn]

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:

• Hardware breakpoint remains armed after Cortex-Debug stops a pyOCD session Marus/cortex-debug#1244
• Hardware breakpoint remains armed after Cortex-Debug stops a pyOCD session Marus/cortex-debug#1244 (comment)

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.

[haneefdm]

Note: In this case, we did not ask for the gdb-server to persist (no --persist). I am not particular about the gdb-server exiting after the last disconnect. But at least it should finish the gdb requests so we can trust gdb when it says it is "^done" that the HW has been updated

Since you can have more than one connection to the same core/tcp-port - even if it auto-exits, it should do so on the last disconnect across all cores. But I can understand this part is tricky and you don't want to do that.

Also, we do not use monitor exit because our end-of-session logic is the same for all gdb-servers, and most do not need/support an explicit exit.

I am open to working with you to do the right thing.