[SOLVED] presumption of breakpoints with RISC-V?

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] presumption of breakpoints with RISC-V?

    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.
  • Hi,

    I tried to reproduce the reported behavior but did not succeed. Since I do not have access to a silicon where I can adjust the number of available hardware BPs I patched the DLL in order to limit the number of HW BPs to 4, 2, 1 and 0 and attempted setting 5 BPs. In all cases the Jlink commander responded properly:
    For 4 available BPs 4 BPs were set but setting the 5th was denied
    For 2 available BPs 2 BPs were set and from the 3rd on all BPs were denied
    For 1 available BP 1 BP was set and from the 2nd on all BPs were denied
    for 0 available BPs all 5 BPs were denied

    So the functionality is as expected.

    Source Code

    1. SetBP 0x80000000 H // H: Force hardware BP
    2. SetBP 0x80000004 H
    3. SetBP 0x80000008 H
    4. SetBP 0x8000000C H
    5. SetBP 0x8000000D H
    I 'd like to add that we can imagine only rare settings where a developer can be happy w/o even a single HW BP, even though the Jlink does support that ;)
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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.
    Files
    • ibex-fpgaRV32.zip

      (4.93 kB, downloaded 412 times, last: )
    • ibex0bkpt.zip

      (119.04 kB, downloaded 408 times, last: )
    • ibex1bkpt.zip

      (127 kB, downloaded 412 times, last: )
    • ibex2bkpt.zip

      (122.15 kB, downloaded 417 times, last: )
  • We still suspect that this issue is related to the disassembly issue you reported in this thread:
    [SOLVED] incorrect decoding of RISC-V instructions

    There is a new version (V6.94c) coming today which fixes the problem reported in the other thread.It will be available for download by this evening (UTC + 1):
    segger.com/downloads/jlink/#J-…twareAndDocumentationPack
    Can you please give this version a try and check if it also fixes the problem here for you?
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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!
  • Thanks for the confirmation.
    Good to hear that you are up and running.
    We will consider these threads as closed.


    BR
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.