Forum Discussion
New ContributorNios V/m JTAG run‑control HALT fails — Debug Module healthy, hart never halts
## Summary
On a Nios V/m soft processor, JTAG **halt** never succeeds: the Debug Module enumerates and answers
DMI cleanly, the hart runs and is resettable via `ndmreset`, but a `haltreq` is ignored — `dmstatus`
stays `0x00400cc3` (`allrunning=1`, `allhalted=0`) indefinitely. `niosv-download`, Intel's OpenOCD
build, and the Ashling RiscFree GDB server **all** fail identically with *"Could not halt the target:
timeout occurred"* / *"Unable to halt … Hart 0 failed to halt during examine"*.
## Environment
- Quartus Prime **Pro 26.1** (Build 110).
- Nios V/m IP `intel_niosv_m` (unit `intel_niosv_m_unit_2600`, debug submodule `intel_niosv_dbg_mod_210`).
- Device: Arria 10 **`10AX022C4U19E3SG`**.
- Programmer: **USB‑BlasterII** (cable index 2). Single device on the chain (`JTAG ID 0x02E220DD`).
- CPU clock: IOPLL `outclk0` = **100 MHz**, PLL locked (verified). Design Fmax = 131.6 MHz (timing met).
## Symptom (verbatim)
```
Internal error. Could not halt the target: timeout occurred (Ashling ash-riscv-gdb-server)
Error: Unable to halt. dmcontrol=0x10000001, dmstatus=0x00400cc3
Error: Fatal: Hart 0 failed to halt during examine (Intel OpenOCD)
```
## Direct DMI evidence (via OpenOCD `aji_client`, low‑level `dmi_read`/`dmi_write`)
- SLD node enumerates: `jtagconfig -n` → `Node 08986E00 Nios V #0`.
- `dmstatus` (running) = `0x00400cc3` → version=3, authenticated, **anyrunning/allrunning=1, allhalted=0**.
- `abstractcs` = `0x08000002` → **progbufsize=8, datacount=2, cmderr=0** (DM healthy).
- `sbcs` = `0x00000000` → **no System Bus Access** in this DM.
- Direct `dmcontrol = 0x80000001` (haltreq + dmactive) → `dmstatus` stays `0x00400cc3` (**allhalted never asserts**).
- `ndmreset` **works**: asserting it sets `dmstatus` havereset bits (→ `0x004c0cc3`); the hart resets and resumes.
- `hasresethaltreq = 0` (halt‑on‑reset not implemented — separate facility, not the cause).
## Exhaustively ruled out
| Hypothesis | Result |
|---|---|
| CPU clock wrong | Fixed/verified 100 MHz, PLL locked |
| Timing closure | Met (Fmax 131.6 MHz) |
| JTAG TCK rate | Tried 24 MHz → 6 MHz (`jtagconfig --setparam … JtagClock`) — no change |
| Debugger choice | `niosv-download` = Intel OpenOCD = Ashling RiscFree — **identical** failure |
| Command timeout | 120 s configured; manual `haltreq` inert |
| `Enable Reset from Debug Module` | Enabled + `dbg_reset_out→ndm_reset_in` looped → `ndmreset` works, **halt still fails** |
| `instruction_manager → dm_agent` mapping | Added; no effect (and PD won't place it in the instruction map) |
| Stale/composed IP generation | **Removed and re‑added a FRESH `intel_niosv_m` (enableDebug=1, enableDebugReset=1), full reconnect + regenerate + recompile → identical failure** |
## Conclusion / request
A correctly‑configured, freshly‑generated Nios V/m core does **not** enter Debug Mode on `haltreq` on this
device/toolchain, although the Debug Module is fully responsive over DMI and `ndmreset` works. Per the
RISC‑V External Debug spec, an *available* running hart must halt within <1 s of `haltreq`; this one
never does. The fault appears to be in the **hart‑side debug (Sdext) halt path** of the Nios V/m IP for
this version/device, or a board‑level JTAG halt‑path issue.
**Questions for Intel/Altera:**
- **Q1.** Is there a known erratum for Nios V/m where the DM enumerates/answers DMI but the hart ignores `haltreq` (`allhalted` never asserts)? Fixed in a specific Quartus Pro / Nios V IP version?
- **Q2.** Beyond `Enable Debug`, is any parameter/connection required for the hart to honor `haltreq`?
- **Q3.** Any documented Arria 10 `10AX022C4U19E3SG` JTAG/SLD interaction with Nios V run‑control halt?
Related (please confirm whether either covers this *post‑enumeration* halt timeout): Intel KB **000096654**;
community thread **1404335**. (KB **000096246** is a different *detection*-only defect — not this.)
3 Replies
JitLoonL_AlteraOccasional Contributor
Hi 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.
- LiangYuG_Altera
Contributor
Would you mind share a photo of your QSYS design?
I can take a look, and see any differences.FYI:
I tested a 26.1Pro Nios V/m design on Arria 10 SoC dev kit (aka 10AS066N3F40E2SG), and the niosv-download is working fine. I don't think there is major JTAG difference between 10AX022C4U19E3SG & 10AS066N3F40E2SG. But let's see how the investigation goes.Regards,
Liang Yu 
tehjingy_AlteraRegular Contributor
Let me know if you have any further clarification needed for this case?
Regards
tehjingy
