Nios 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.)