Detailed description
- This is not a new feature.
- The existing problem is RISC-V triggers (breakpoints/watchpoints) can get stuck in the target if BMP suddenly disappears (JTAG disconnected, or USB/firmware reset, or BMDA terminated).
- The PR solves that by resetting tdata1/tdata2 to zero in
riscv_attach() & riscv_detach().
Normally GDB is supposed to set-unset all break/watch points (Z/z-packets) on every halt/resume, and remove them before detach. However, for unrelated reasons, when I used blackpill-f411ce against GD32VF103CB, sometimes it got stuck busy-looping during ordinary step/next/finish commands (automatically using hardware breakpoints). Then I Ctrl+C out twice from GDB to disconnect, do a usbreset 003/012 against "BMP", tio notifies me it Disconnected/Connected to ttyBmpTarg, and again I start GDB, scan, attach, continue debugging -- here GDB/BMP don't know that some of 4 triggers are in use, will report SIGTRAP when these hit, but won't let me easily remove them. One workaround is to enqueue 4 different breakpoints and resume+halt once; another is to power-cycle the target (which is not applicable to every board, consider battery-powered devices).
This is also reproducible with BMDA. Additionally, if you try to step/continue across any watchpoint that hits, GDB+BMD busyloop each other with "breakpoint hit" (actually watchpoint) -- "vCont" with no way out. I suppose this is a separate issue, but clearing out triggers helps to back out of it.
Cortex-M layer clears out FPB and DWT comparators during attach/detach, Cortex-A/R layer clears out DBG_WCR/WVR (watchpoint control/value) of Debug Unit during attach/detach, too. I'm not sure why, and I also have opinions about DWT being possibly used by firmware for realtime trace. But let's bring RISC-V layer to feature parity with them.
Question for testing. What happens on targets which implement 0 trigger slots? WARL semantics allow both loops to execute once with no side effects? There is another issue where BMD reports 1 trigger discovered (0++ equals 1) even if it's not implemented.
Your checklist for this pull request
Closing issues
## Detailed description
* This is not a new feature.
* The existing problem is RISC-V triggers (breakpoints/watchpoints) can get stuck in the target if BMP suddenly disappears (JTAG disconnected, or USB/firmware reset, or BMDA terminated).
* The PR solves that by resetting tdata1/tdata2 to zero in `riscv_attach()` & `riscv_detach()`.
Normally GDB is supposed to set-unset all break/watch points (Z/z-packets) on every halt/resume, and remove them before detach. However, for unrelated reasons, when I used `blackpill-f411ce` against GD32VF103CB, sometimes it got stuck busy-looping during ordinary step/next/finish commands (automatically using hardware breakpoints). Then I Ctrl+C out twice from GDB to disconnect, do a `usbreset 003/012` against "BMP", `tio` notifies me it Disconnected/Connected to ttyBmpTarg, and again I start GDB, scan, attach, continue debugging -- here GDB/BMP don't know that some of 4 triggers are in use, will report SIGTRAP when these hit, but won't let me easily remove them. One workaround is to enqueue 4 different breakpoints and resume+halt once; another is to power-cycle the target (which is not applicable to every board, consider battery-powered devices).
This is also reproducible with BMDA. Additionally, if you try to step/continue across any watchpoint that hits, GDB+BMD busyloop each other with "breakpoint hit" (actually watchpoint) -- "vCont" with no way out. I suppose this is a separate issue, but clearing out triggers helps to back out of it.
Cortex-M layer clears out FPB and DWT comparators during attach/detach, Cortex-A/R layer clears out DBG_WCR/WVR (watchpoint control/value) of Debug Unit during attach/detach, too. *I'm not sure why, and I also have opinions about DWT being possibly used by firmware for realtime trace.* But let's bring RISC-V layer to feature parity with them.
Question for testing. What happens on targets which implement 0 trigger slots? WARL semantics allow both loops to execute once with no side effects? There is another issue where BMD reports 1 trigger discovered (0++ equals 1) even if it's not implemented.
## Your checklist for this pull request
* [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md)
* [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository
* [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware))
* [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app))
* [x] I've tested it to the best of my ability
* [x] My commit messages provide a useful short description of what the commits do
## Closing issues