For RISC-V targets, there appears to be an implicit assumption by SEGGER that the target has hardware breakpoints (or "triggers" in RISC-V nomenclature), and there is no warning to user when the SEGGER tools try to leverage more breakpoints than are available.

This is despite SEGGER J-Link Commander decoding and displaying the number of RISC-V hardware breakpoints when initially connecting to the target.

Debug architecture:
RISC-V debug: 0.13
AddrBits: 7
DataBits: 32
IdleClks: 1
Memory access:
Via system bus: Yes (32-bit accesses are supported)
Via ProgBuf: Yes (8 ProgBuf entries)
DataBuf: 2 entries
autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
Temp. halted CPU for NumHWBP detection
HW instruction/data BPs: 2
Support set/clr BPs while running: No
HW data BPs trigger before execution of inst
RISC-V identified.

Testing was done with the latest J-Link release (v6.94). I have demonstration code using SEGGER Embedded Studio.

For J-Link Commander, there is no warning if more breakpoints than those are available are added. If more breakpoints are added, the target triggers an exception instead of executing user code.

For SEGGER Embedded Studio, there are similarly no warnings. If there are not at least two hardware breakpoints, the IDE fails to debug even simple example code properly. With zero breakpoints, the target is shown to branch to an erroneous address. With one breakpoint, the IDE gets stuck when single-stepping code. With two breakpoints, simple example code runs, but my concern is that it will not warn the user if more complex code causes the IDE to uses more breakpoints than are available.

My target is a RISC-V core (Ibex RV32IMC) with RISC-V debug (pulp riscv-dbg v0.13) on an Arty A7-A35T FPGA board (segger.com/evaluate-our-software/risc-v/digilent-arty/).

I realize that SEGGER may not have previously tested such a configuration, but since SEGGER says in its sales verbiage that J-Link should support any custom RISC-V core providing it supports RISC-V 0.11, RISC-V 0.13 (what the target is), or RISC-V DAP, it seems worth pointing out this issue.

segger.com/products/debug-prob…d-devices/risc-v-support/

I would be happy to provide SEGGER with example code and Arty A7-A35T FPGA bitstream images for them to reproduce the problem.

I have attached example code (lightly modified SES default project). Most importantly, I have attached three different versions of FPGA image with 0, 1, and 2 hardware breakpoints respectively. These images can be loaded onto Arty A7-A35T FPGA board (segger.com/evaluate-our-software/risc-v/digilent-arty/).

With this, you should be able to see the same behavior.

I hear what you are saying about the usefulness of hardware breakpoints, but SEGGER makes a point of "unlimited breakpoints" in flash, and replacing instructions in SRAM (attached example) with breakpoint instructions (without needing a hardware interrupt) is comparatively trivial.

I can confirm that V6.94c addresses the problems in both threads. Despite a limited number of hardware breakpoints (even zero), SES judiciously makes use of software breakpoints and makes debugging possible. Thanks!