RISC-V Timer Interrupt Trap
pending interrupt -> trap entry -> handler -> return
U-mode is running
Async interrupt conditionU-mode is running, a supervisor timer interrupt is pending, and the relevant interrupt trap conditions are satisfied. STIP means a supervisor timer interrupt is pending; STIE is the enable bit for cause 5; the current-privilege/global-enable conditions must also allow delivery. This step only states that the trap conditions hold; the edge from node 1 to node 2 represents the interrupt trap being taken.
STIP may be set by SEE/SBI/M-mode software, or by the stimecmp comparison under Sstc; this page collapses the source into an already-pending condition.
Boundaries that often get mixed up
A timer interrupt is asynchronous; EPC records the interrupted location, not an ECALL-style next instruction.
In a delegatable U/S context, mideleg[5] changes the S/M trap target, not the low cause code 5 or interrupt bit; it does not demote an M-mode trap.
The main graph does not model mtime/mtimecmp, Sstc stimecmp, SEE/SBI, or a concrete OS tick; under Sstc, STIP may also reflect the comparison with latency.
This page starts after U-mode is interrupted by a supervisor timer interrupt that is already pending and deliverable, using a simplified non-virtualized U/S/M trap-routing model. The official privileged architecture defines STIP/STIE, cause 5, mideleg, trap entry/return, and optional Sstc stimecmp; here, mideleg only affects target selection for delegatable contexts and does not route M-mode traps to S-mode. Under Sstc, STIP's reflection of the stimecmp comparison need not be immediate, so software must still tolerate occasional spurious timer interrupts. H-extension MPV/SPV/VS return state, concrete platform timer devices, mtime/mtimecmp mappings, SEE/SBI/firmware, interrupt controllers, and OS tick policy are outside this page's claims.