Hardware breakpoint remains armed after Cortex-Debug stops a pyOCD session

[CaFeZn]

Describe the bug

When ending a Cortex-Debug session that uses pyOCD, a hardware breakpoint can remain programmed in the target's FPB comparator even though Cortex-Debug has issued break-delete and GDB reports success.

This reproduces with both Stop and Disconnect and Suspend. After the debug session has ended, asserting the board's hardware NRST still causes the target to halt at the old breakpoint. A later non-initializing SWD diagnostic read shows that the halt is a breakpoint event and that the old FPB comparator remains enabled.

As a diagnostic control, I manually issued a DAP disconnect request equivalent to:

{
  "terminateDebuggee": false,
  "suspendDebuggee": false
}

This exact plain-disconnect action is not exposed by the VS Code UI in this setup. It follows the detach path and does not reproduce the issue. This is evidence that distinguishes the two shutdown paths, not a user-accessible UI workaround.

Steps to reproduce

1. Start a Cortex-Debug session using "servertype": "pyocd" and a CMSIS-DAP probe.
2. Set a code breakpoint and continue until it is hit.
3. End the session using Stop or Disconnect and Suspend.
4. Assert hardware NRST after the debug session has ended.
5. Observe that the target halts again at the old breakpoint location.
6. Read the Cortex-M debug registers without target initialization. The stale FPB comparator is still enabled.

Expected behavior

All breakpoint removals should be committed to the target before the managed pyOCD process is terminated. After the session ends, no FPB comparator from that session should remain enabled, and NRST should not cause the target to halt at the old breakpoint.

Observed command sequence

The following is a shortened and sanitized sequence. Probe identifiers have been removed.

VS Code -> disconnect { terminateDebuggee: true }
Cortex-Debug -> <N>-break-delete
GDB -> <N>^done

GDB -> pyOCD: z1,<BREAKPOINT_ADDRESS>,2
pyOCD -> GDB: OK

Cortex-Debug -> terminates the managed pyOCD server process

No subsequent breakpoint insertion was observed after break-delete.

The evidence suggests that pyOCD updates its pending breakpoint state and replies OK, but the physical write that clears FP_COMP is not flushed before the process is terminated.

Hardware register evidence

After the session had ended and hardware NRST had been asserted, a non-initializing diagnostic read showed:

PC        = 0x08000804
DFSR.BKPT = 1
FP_COMP0  = 0x08000805

After explicitly clearing the stale comparator, a second read showed no enabled FPB comparator and the old breakpoint no longer remained.

Related issues

• GDB server gets killed too early on debug stop, causing the target to halt #1122 reports the same general pyOCD shutdown race: Cortex-Debug force-kills the server before it completes a graceful exit. That issue reports the target remaining halted, but does not include z1, FP_COMP, or stale hardware-breakpoint evidence.
• pyocd does not issue ID_DAP_Disconnect on end of debug session in Eclipse pyocd/pyOCD#1531 reports that an IDE terminating pyOCD with SIGTERM can prevent normal cleanup and DAP disconnect. It does not discuss hardware breakpoint removal.
• Flash software breakpoints are not cleared when exiting debug session #374 concerns stale flash software breakpoints, not FPB hardware comparators.

Environment

• OS: Windows 11
• VS Code: 1.125.1
• Cortex-Debug: 1.12.1
• pyOCD: 0.45.1
• Arm GNU GDB: GNU Tools for STM32 13.3.rel1.20240926-1715 / GDB 14.2.90.20240526-git
• Target: STM32C552CCU6 / Cortex-M33
• Probe: CMSIS-DAP; serial number intentionally omitted
• Session request: attach

Additional logs

Full sanitized Cortex-Debug, pyOCD, and GDB RSP traces can be provided if needed. Probe identifiers, user names, and local paths will be omitted.

Could Cortex-Debug allow the managed pyOCD process to complete its graceful cleanup before force termination, or use a pyOCD-specific graceful termination mechanism? If the current termination sequence is intentional, please confirm so the same trace can be followed up in pyOCD.

[haneefdm]

Thanks for reporting this issue and your investigation. Could I ask you try the latest build? Both the start and end of session have gone through so many changes. We didn't even know that pyOCD does not actually remove breakpoints and instead keeps them in a pending state. Do you know why pyOCD does this? We never talk to the gdb server (pyOCD). We only talk to gdb and if gdb says it is done...we don't question that.

https://github.com/Marus/cortex-debug/releases

We only kill the server if it does not exit naturally. But something else may have happened. The last few lines from the moment you hit the disconnect/stop button tells is a lot in the debug console

[CaFeZn]

Thank you for the response. First, I need to correct the version in my original report: the session that reproduced the problem was already using Cortex-Debug 1.13.0-pre9, which is currently the latest release. The captured adapter log contains pvtVersion: 1.13.0-pre9. I mistakenly reported 1.12.1 because I queried the installed-extension list later, after VS Code had switched back to the stable version. Sorry for the confusion.

I do not know why pyOCD keeps the breakpoint removal pending. I am not an expert in debugger internals; I encountered this as a user and asked Codex to help collect evidence and analyze the sequence. The explanation about a pending hardware write or missing flush is a hypothesis inferred from the break-delete / z1 / OK ordering and the later FP_COMP register state. It is not direct knowledge of pyOCD's design, and I am happy to revise that interpretation based on maintainer feedback.

I will have access to the hardware again tomorrow. Please let me know exactly which information or tests would be most useful. I can perform a clean reproduction with 1.13.0-pre9 and provide sanitized console logs for each of these cases:

1. Stop from the VS Code UI.
2. Disconnect and Suspend from the VS Code UI.
3. A manually issued plain DAP disconnect request with terminateDebuggee: false and suspendDebuggee: false, as a diagnostic control. This third action is not exposed by the UI in my setup.

For each case I can capture the final Cortex-Debug Debug Console lines from the action through GDB and pyOCD exit, with raw adapter output and timestamps enabled. I can also provide pyOCD verbose logs, the GDB RSP sequence around z1, and the DFSR / FP_COMP state after hardware NRST if those would help.

I will redact probe identifiers, user names, and local paths before posting the logs.

[haneefdm]

Thanks, I will take a look at it. But with "showDevDebugOutput": "raw", if you can copy/paste the last 30-40 lines from the Debug Console, it will save me some time. I just need to know what we did

If pyOCD is indeed doing what Codex is saying, then it should be an issue with pyOCD. It cannot just lie to us like that. A lot of gdb-servers get the detach/disconnect implementation wrong. I corrected OpenOCD and worked with SEGGER on JLink. Not saying pyOCD is wrong but it is suspicious.

[haneefdm]

Also look in your system tmpdir for a file cortex-debug-server.log, more than likely in C:\Users\USERNAME\AppData\Local\Temp

We put some stuff in there because when something horribly goes wrong, there is no debug console and no stdout/stderr. The last few lines will tell you if we killed pyOCD forcibly.

[CaFeZn]

Thank you. I repeated the test with Cortex-Debug 1.13.0-pre9 as requested, with:

"showDevDebugOutput": "raw"

This test used a pyOCD attach session. The relevant configuration was:

"request": "attach",
"servertype": "pyocd",
"serverArgs": [
    "-O",
    "dap_protocol=swd",
    "--probe",
    "<REDACTED>",
    "--connect",
    "attach"
],
"postAttachCommands": [
    "continue"
]

I did not manually issue Continue after starting the attach session. The program resumed automatically and then hit the hardware breakpoint at main.c:80, corresponding to address 0x08000804.

While the target was stopped at that breakpoint, I explicitly selected Stop from the VS Code debug-session exit menu.

The raw Debug Console tail from clicking Stop until the session ended was:

Client (vscode?) requested end of debug session:
{"restart":false,"terminateDebuggee":true}

23-break-delete
-> 23^done

24-target-disconnect
-> =thread-exited,id="1",group-id="i1"
-> =thread-group-exited,id="i1"
-> 24^done

-gdb-exit
-> ^exit
GDB session ended. exit-code: 0

The tail of cortex-debug-server.log from the same shutdown was as follows. I have redacted the process IDs:

[2026-07-24T03:34:22.899Z] ppid=<PID> pid=<PID> CMSIS-DAP SWD (Attach): Begin disconnectRequest
[2026-07-24T03:34:22.942Z] ppid=<PID> pid=<PID> GDB: exited
[2026-07-24T03:34:22.944Z] ppid=<PID> pid=<PID> CMSIS-DAP SWD (Attach): quitEvent: Killing server
[2026-07-24T03:34:22.945Z] ppid=<PID> pid=<PID> GDBServer(<PID>): forcing an exit with kill()
[2026-07-24T03:34:22.946Z] ppid=<PID> pid=<PID> CMSIS-DAP SWD (Attach): disconnectRequest sendResponse 3
[2026-07-24T03:34:22.965Z] ppid=<PID> pid=<PID> CMSIS-DAP SWD (Attach): quitEvent: sending VSCode TerminatedEvent
[2026-07-24T03:34:22.967Z] ppid=<PID> pid=<PID> GDBServer(<PID>): exited code=null signal=SIGTERM

After Stop completed, the relevant target registers were:

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

I then performed a hardware reset using the now-wired NRST signal and waited approximately 1.8 seconds. The resulting state was:

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

So in this run, both break-delete and target-disconnect reported success in the MI output, followed by a normal GDB exit. The server log then shows Cortex-Debug forcibly terminating the still-running pyOCD process. The hardware FP_COMP0 comparator nevertheless remained enabled, and after NRST the target stopped again at the old breakpoint address.

At this point I can confirm the observed sequence and the physical register state, but I cannot determine whether the fix belongs in Cortex-Debug or pyOCD. If you need another specific log, the complete raw output, or a particular control test, please let me know the exact procedure and I can collect it.

[haneefdm]

In this case, the request was {"restart":false,"terminateDebuggee":true} so cortex-debug did the right thing. This is NOT a request to detach. pyOCD was supposed to exit on its own after the last disconnect. It didn't and we can't wait around for it. We kill it or else it will leave the USB port tied up and leave a zombie process, so further debugging would become difficult. We apply this policy to all gdb-servers.

After you start with an attach or launch session Stop button has a drop-down (tiny down arrow) and you can exercise two options for how to stop. The wording used by VSCode is confusing, but one gets used to it. We have no control over that. If you hover on the button, it also shows the keyboard shortcuts for the same.

We tried putting a delay before killing the gdb-server but that didn't work as most gdb-servers refused to quit causing worse issues with the USB port.

I still think, pyOCD needs a justification for not finishing the breakpoint deletion. Regardless of detach vs disconnect. The delete breakpoints command is a "command", not a "suggestion".

From all of this, I am concluding that pyOCD needs a fix. Please report it to them. They are generally pretty good at responding.