Debugging Issue with Nios® V Processor Using Ashling RiscFree IDE on Agilex® 7 FPGA

[fa_fpga_enthusiast]

Hello,

We are encountering an issue while debugging our application on the Nios® V processor implemented on an Agilex® 7 FPGA, using the Ashling RiscFree IDE. The problem occurs after the first successful debug session. When attempting to debug the application a second time, the debugger jumps to the following section of code in crt0.S:

#if ALT_CPU_HAS_CSR_SUPPORT
/* assume that we are in machine mode on startup */
/* setup trap to catch anything that goes wrong early in the boot process */
la t0, trap_vector
csrw mtvec, t0

/* disable all interrupt */
li t0, 0x88
csrc mstatus, t0
csrw mie, zero
csrw mip, zero
#endif

At this point, we receive the error:
Error: Operation failed: "Command Aborted"

To debug the application again, we are forced to reprogram the FPGA with the SOF file each time. We are looking for a solution to avoid this reprogramming step while debugging repeatedly.

Additional Observations

• Run Mode Works: Using "Run As > 3 Ashling RISC-V Hardware Debugging" allows us to run the application multiple times without reprogramming the FPGA.
• Connection of dbg_reset_out: Following the guidelines in "AN 978: Nios® V Processor Migration Guidelines," the dbg_reset_out signal is not connected to the reset signal of the Nios® V. However, we tested connecting these signals, but it made no difference to the issue.
• QSYS Configuration: We have attached an image showing the connections of the various subsystems in the Platform Designer (QSYS).

Could you please advise us on how to address this issue?

Thank you in advance for your assistance!

[JingyangTeh_Altera]

Hi

Are you using the Quartus Project newer than Quartus 24.2?

If yes could you try creating your project in 24.2?

Regards

Jingyang, Teh

[fa_fpga_enthusiast]

Hello,

Thanks for your response!

We are currently using Quartus Prime Pro 23.4 since we work with both Nios II and Nios V. We plan to upgrade to a newer version in the future.

For now, we have found a workaround: Before terminating the debug session, we use the "Restart a process or debug target without terminating and re-launching" button in the Ashling RiscFree IDE. This forces the debugger to jump to the beginning of the application before termination, allowing the next debug session to start properly. However, we would prefer to avoid this workaround.

We will update you once we test with a newer version of Quartus Prime Pro, but this will take place later.

Best regards.

[JingyangTeh_Altera]

Hi

Thanks for confirming the workaround!

For this workaround in some case, it is not working for some case.

Please try to upgrade the Quartus version 24.2.

Regards

Jingyang, Teh

[JingyangTeh_Altera]

Hi

I’m glad that your question has been addressed, I will now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Regards

Jingyang, Teh