- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am using Arrow Electronics Agilex-5 AXE5-Eagle development kit with a simple NiosV/m design and Hello World application that just prints using printf(). The stdout is directed to the JTAG UART.
I am using USB Blaster for connecting to the board.
The application works. I am also able to debug the application code (using the Ashling IDE).
However, when the Ashling GDB Server starts, the following messages are printed (note the ones I marked in red):
Ashling GDB Server for RISC-V (ash-riscv-gdb-server).
v24.4.0, 27-Sep-2024, (c)Ashling Microsystems Ltd 2024.
Initializing connection ...
Cannot set the JTAG frequency, continuing with auto adjust mode
Failed to get JTAG frequency from the debug probe
Connected to target device with IDCODE 0x364f0dd using USB-Blaster-2 (1) via JTAG at 0.00MHz.
Info : Active Harts Detected : 1
Info : Core[0] Hart[0] is in halted state
Info : [0] System architecture : RV32
Info : [0] Number of hardware breakpoints available : 1
Info : [0] Number of program buffers: 8
Info : [0] Number of data registers: 2
Info : [0] Memory access -> Program buffer
Info : [0] Memory access -> Abstract access memory
Info : [0] CSR & FP Register access -> Abstract commands
Waiting for debugger connection on port 55304.
Press 'Q' to Quit.
Got a debugger connection from 127.0.0.1 on port 55304.
In the Ashling IDE, Debugger settings, I have tried "JTAG frequency" from 1 MHz to 16 MHz - no difference.
In the sample design, the Nios V/m is run at 100Mhz. I also had it at 25 Mhz - no difference.
Two questions:
1. What should I try in order to resolve the above red lines?
2. While debugging works, it is kind of slow - for example making a step takes 4-5 seconds. Is this the expected speed for a single debug step?
Thank you,
d.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @dim1,
Thank you for posting in Intel community forum and hope all is well.
Could you help us to understand further on the environment (i.e., OS) that you have and which version of quartus you are having?
As for the comment on the 2 question you have as below:
1. What should I try in order to resolve the above red lines?
- The message are just a warining and not fatal error which could be reason such as USB blaster or Askling GDB server instabilities. Since the connection works and debugging are functioning, we can ignore for now.
2. While debugging works, it is kind of slow - for example making a step takes 4-5 seconds. Is this the expected speed for a single debug step?
- Maybe the actual issues where some JTAG settings are failing or program buffer limits. Would suggest to force the JTAG frequency from Askling IDE manually via CLI (i.e., --jtag-freq 16000 or using .ini/config override). Also perhaps to check on the quartus programmer JTAG test by running quartus_pgm --auto with a .sof file and see if it reports a JTAG frequency. Last but not least try running the jtagconfig --debug to confirm the actual JTAG frequency or failure to set it
Hope that clarify
Best Wishes
BB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi BB,
Thank you for your response.
At the moment I am using Quartus Prime Pro, 24.3.1, on Windows 10.
I am going to try with Quartus Prime Pro 25.1 as well.
I tried quartus_pgm and jtagconfig, but neither reports JTAG frequence. For example, for jtagconfig:
[niosv-shell] C:\intelFPGA_pro\24.3.1\quartus\bin64> jtagconfig --debug
1) USB-Blaster [USB-0]
(JTAG Server Version 24.3.1 Build 102 01/14/2025 SC Pro Edition)
0364F0DD A5E(C065BB32AR0|D065BB32AR0) (IR=10)
Design hash FB2EBE61EF52C558ABA3
+ Node 08986E00 Nios V #0
+ Node 0C006E00 JTAG UART #0
Captured DR after reset = (0364F0DD) [32]
Captured IR after reset = (001) [10]
Captured Bypass after reset = (0) [1]
Captured Bypass chain = (0) [1]
I noticed that the Ashling tools are referencing/looking for USB Blaster II. At the moment I am using USB Blaster (not USB Blaster II). Could this be the reason for not being able to set/see JTAG Frequency and the slow debugging speed?
I do not have USB Blaster II at the moment to try with, but will try to find one.
Thank you,
d.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @dim1,
Thanks for sharing the response from the jtagconfig, it seems that the frequency are not able being picked up/supported from the connection.
Highly suspect it could be the USB blaster I behavior causing this, and yes would suggest to use the USB Blaster II which support configurable and faster JTAG frequency.
Do let us know once you managed to found one and try it out.
Hope to hear from you soon.
Best Wishes
BB

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page