New Contributor
Occasional ContributorHi relsaar_design
Your isolation here is spot on. The DMI evidence (abstractcs = 0x08000002 and dmstatus = 0x00400cc3) definitively proves that the JTAG chain, SLD Hub, and the RISC-V Debug Module (DM) are completely healthy and authenticated.
The symptom you are describing (dmstatus remaining running, haltreq timing out) is the classic hallmark of an Avalon bus hang. In the RISC-V architecture, entering Debug Mode via an external debug request (haltreq) is a non-maskable trap, but the hart must be able to cleanly retire its current instruction or flush its pipeline to take that trap and jump to the debug ROM.
If the Nios V hart comes out of reset and immediately issues an instruction fetch to the Avalon-MM fabric, and the slave never completes the transaction (e.g., holding waitrequest high indefinitely, or failing to assert readdatavalid), the processor pipeline stalls permanently. A frozen hart physically cannot process the haltreq from the DM, resulting in the exact timeout and OpenOCD aborts you are seeing. (The riscv-openocd project tracks this precise behavior under Issue #195: a blocked memory bus prevents the debugger from halting the hart during examine).
Direct Answers to Your Questions
Q1. Known Erratum?
There is no publicized, unresolved erratum for Quartus Pro 26.1 stating the IP fundamentally ignores haltreq post-enumeration. The issue is almost certainly an architectural response to a stalled memory interface rather than a bug in the intel_niosv_m halt logic itself.
Q2. Required Connections/Parameters?
Yes. The Reset Vector and Exception Vector must point to fully initialized, mapped, and responsive memory. Furthermore, Nios V is strictly a 32-bit master. If your memory subsystem (e.g., OCRAM or external flash) is configured for 16-bit or 8-bit data widths without an Avalon-MM Pipeline Bridge to handle the width adaptation, the interconnect fabric can silently hang. This is the exact root cause behind Intel KB 000096654, which you referenced; the width mismatch causes a bus hang, leading directly to Ashling IDE timeouts.
Q3. Arria 10 JTAG/SLD Interactions?
There are no documented fundamental incompatibilities here. Your DMI reads confirm the SLD hub is flawless. The failure boundary is strictly isolated to the Hart-to-Avalon interface, not the JTAG-to-SLD path.
Recommended Troubleshooting Steps
To prove the bus is hanging immediately after ndmreset is released, I recommend the following:
Signal Tap the Avalon Masters
Drop a Signal Tap instance onto the Nios V Instruction Master and Data Master interfaces. Trigger on the rising edge of read or write. You will likely see the master assert a read for the reset vector, and the fabric either never responds with readdatavalid or holds waitrequest high indefinitely.
Verify Reset Vector Target
Double-check the memory component assigned to the Reset Vector in Platform Designer. Ensure it is not being held in reset by a different clock/reset domain, and that its driving clock is actively toggling and locked.
Audit Data Widths
Check all memory slaves connected to the Nios V instruction and data masters. If any are not 32-bit, insert an Avalon-MM Pipeline Bridge between the Nios V and the slave to ensure proper fabric translation.
