Smdbltrp names the failure the MDT bit was invented for — a trap striking M-mode before its handler has saved state — and turns it into a defined escalation instead of silent corruption.
The few instructions between trap entry and saving mepc are the most
fragile code on the machine. A second trap there overwrites the only
record of the first, and execution carries on from a lie.
A one-page chapter naming the extension whose machinery you’ve already met: mstatus.MDT (ch. II·3, §3.1.6.2) turns the worst-case failure — a trap striking M-mode before the handler saved its state — from silent corruption into a defined escalation ladder:
- RNMI handler, when Smrnmi is implemented and
mnstatus.NMIE = 1: mnepc/mncause receive what the double trap would have written to mepc/mcause — resumable diagnosis. - Critical-error state otherwise (or when the double trap strikes inside the RNMI handler): execution ceases with architectural state untouched, all interrupts (NMIs included) disabled, and a critical-error signal asserted to the platform — which may restart the hart, the platform, or anything else it deems fit.
- Debug Mode entry as an alternative to the critical-error signal, for bench diagnosis of harts in the critical error state (per the Debug specification).
The recap of the MDT protocol: reset leaves MDT=1; every trap into M sets it; MRET/SRET-in-M clear it; writing MDT=1 clears MIE; RNMI traps neither count as unexpected nor set MDT.
- MDT is the entire mechanism: reset leaves it 1, every trap into M-mode sets it, MRET (or SRET taken in M) clears it, and writing MDT=1 clears MIE.
- A double trap escalates rather than corrupts — to the RNMI handler when Smrnmi is present with NMIE=1, otherwise to the critical-error state, which freezes architectural state and signals the platform.
- RNMI traps neither count as unexpected nor set MDT. The two extensions interlock on purpose, so the diagnosis path is never the thing that trips the detector.
Hardware Designer Notes
For a Linux-class core, Smdbltrp is cheap insurance once Smrnmi exists: the MDT flop and escalation mux are a few dozen gates, and firmware gains a guaranteed-sane failure mode for its most fragile code path.
Minimal Linux-boot hart MUST
- Nothing beyond the p03 MDT implementation — this chapter adds the name, the Smrnmi interlock, and the debug hook
MAY simplify / trap-and-emulate
- Route the critical-error state to your debug module instead of (or before) the platform signal
Check yourself — double trap
1.Rank the escalation ladder when a trap hits M-mode with mstatus.MDT already set.
2.Why does the critical-error state deliberately preserve architectural state (no pc/CSR updates)?