Search Results

Quote from SEGGER - Nino: “ All you need to do is a J-Link selected in target options. If the DAP-Link is installed correctly on your System you should be able to debug. ” Alas, this does not seem to be the case locally. Every CMSIS-DAP target I try with such a procedure results in: J-Link V6.96 Emulator Selection No emulators connected via USB. Do you want to connect to a J-Link via TCP/IP instead? However, I can connect to the same targets on the same PC via Rowley Crossworks for ARM, OpenOCD,…

SEGGER has a press release that claims: "SEGGER Embedded Studio now supports DAP-Link": segger.com/news/segger-embedde…io-now-supports-dap-link/ and even on this forum the claim from SEGGER personnel was "CMSIS-DAP is currently only supported in Embedded Studio": [SOLVED] Does Ozone support CMSIS-DAP? but yet there is no sign in Embedded Studio (V5.40b) that such a capability exists (the only target options are J-Link, GDB, and Simulator), and the release notes give no indication that it was rem…

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!

Thank you.I appreciate that you took the time to look seriously at this. For what it is worth, supposedly, the PULP riscv-dbg IP has been in several ASIC tape outs already, but perhaps this is the first (so far) instance of a SEGGER (rather than OpenOCD) user attempting it. OpenTitan (backed by Google, Seagate, Nuvoton, Western Digital, and lowRISC) uses the same implementation, so I believe SEGGER's added effort will prove to be worthwhile in the future. Just as aside, although you didn't make …

Well, this was an interesting problem. I believe the issue you experienced is due to SEGGER performing writes in a non-compliant manner. To explain this, it is necessary to refer to the RISC-V External Debug Support specification, which is available here: riscv.org/wp-content/uploads/2019/03/riscv-debug-release.pdf I wrote some code to sniff the w4 and w2 instructions. (Thank you so much for specifying the exact test conditions you used; that made my life a lot easier.) The first few SEGGER JTAG…

The connector pinouts follow the SiFive de facto convention ([SiFive Freedom E310 Arty FPGA Dev Kit Getting Started Guide](sifive.com/documentation/freed…it-getting-started-guide/)) (see Section 2.2): | PMOD header JD | | | ------------ | ------------ | | 1 : TDO | 7 : TDI | | 2 : TRST_N | 8 : TMS | | 3 : TCK | 9 : RESET_N | | 4 | 10 : | | 5 : GND | 11 : GND | | 6 : VREF | 12 : VREF | It should be a direct substitution for any existing SiFive Arty test setup that SEGGER has. Per the SES project …

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, a…

In your test, you are using a different memory offset. The position of the instruction in memory seems to impact J-Link's ability to decode. I've attached two sample projects. ibex-ledelf.zip contains the original code; ibex-jumpdup.zip was a quick hack-up of the sample SES project to replicate the same jump instruction at the same memory location. For completeness, I've also attached a two breakpoint version of the Ibex RISC-V that can be loaded onto the Arty A7-A35T FPGA board that SEGGER prom…

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: V…

I'm encountering a problem where SEGGER tools are not correctly decoding RISC-V instructions. 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/). It works fine with OpenOCD, but SEGGER has problems with it. J-Link Commander doesn't correctly decode and single-step instructions (and Embedded Studio also trips over itself at the same point). Testing was done with the latest J-Link…

The V6.46h J-Link release notes make multiple mentions of "RISC-V behind a DAP as setup" / "RISC-V behind a DAP setups" / "RISC-V behind a DAP as setup". It suggests RISC-V debug is now feasible through an ARM DAP, including via SWD. Is this a RISC-V debug interface memory mapped into a CoreSight bus, or something else? What are the vendor and part number(s) for the implementation that Segger now supports? Where is the specification for how RISC-V debug is implemented "behind a DAP"? Thanks.