Does WFI always put the processor into low-power sleep?
No. WFI is not a HINT instruction, but its official semantics still allow an implementation to stall or to legally continue as a NOP.
WFI
RISC-V WFI Instruction Details
Instruction ManualI-typeWait-for-interrupt instruction: an implementation may stall the hart until an interrupt might need service, or legally avoid stalling and continue as a NOP.
Instruction Syntax
wfi
Operand Breakdown
Destination rd: general-purpose register receiving the result.
Source rs1: register holding the first operand.
Immediate imm: 12-bit signed value, sign-extended before operation with rs1.
PrivilegedSystem & Privileged
Instruction Behavior
WFI informs the implementation that the current hart may be stalled until an interrupt might need service. It is not a HINT instruction and does not provide a portable low-power guarantee: an implementation may avoid stalling and return as if WFI were a NOP. If a locally enabled interrupt is already pending or later becomes pending, WFI may resume and the corresponding interrupt trap is taken on a following instruction boundary. The privileged architecture also defines the mstatus.TW restriction for lower-privilege WFI execution: an implementation may raise an illegal-instruction exception after an implementation-specific bounded time, and may choose to trap immediately. When S-mode is implemented, U-mode WFI raises an illegal-instruction exception regardless of TW unless it completes within that implementation-specific bounded time.
WFI Decode And Wait Animation
Shows the fixed SYSTEM encoding, TW restriction, and ISA-visible WFI behavior: it may stall or may return as a NOP.
no explicit operands
wfiwfi
31..20
19..15
14..12
11..7
6..0
000100000101
funct12
00000
rs1=x0
000
funct3
00000
rd=x0
1110011
SYSTEM
Wait State
instruction
0x10500073
opcode
1110011 -> SYSTEM
funct3
000 -> privileged non-CSR form
fixed
funct12=000100000101, rs1=x0, rd=x0
permission
M-mode example may reach WFI semantics
wait
implementation may stall the hart
resume
local enabled interrupt pending -> resume
next
resume; trap may be taken on a following instruction
This animation does not promise sleep duration, power reduction, wake latency, or scheduling policy; those are not portable WFI ISA semantics.
Quick Understanding & Search Notes
WFI can wait for an interrupt but does not guarantee sleep. It is not a HINT instruction, has no explicit operands, and has a fixed encoding; execution may stall the hart or may immediately continue as a NOP. Portable software must recheck the wait condition after WFI returns.
In the SYSTEM encoding, funct12=000100000101, rs1=x0, rd=x0, and funct3=000.
An implementation may resume for any reason or treat WFI as a NOP; the specification does not guarantee sleep duration or power behavior.
A locally enabled pending interrupt can make WFI resume; mstatus.TW can restrict lower-privilege WFI, while implemented S-mode gives U-mode a separate bounded-time illegal-instruction condition.
Common Usage Scenarios
Idle loop power saving
Understand this scenario with real code like «wfi # Wait for interrupt».
Low-power waiting
Understand this scenario with real code like «wfi # Wait for interrupt».
Pre-Use Checklist
Syntax Check
- Verify the immediate field is within the valid range.
- Confirm source register rs1 points to the correct operand.
Semantic Check
- Check if the immediate sign-extension matches expectations.
- Ensure the result register rd has a clear purpose.
Pitfalls / Common Confusions
WFI is not a HINT instruction; an implementation may still avoid stalling and return as a NOP.
Do not use WFI as a fixed-delay primitive, portable power guarantee, or scheduler mechanism.
WFI can resume for locally enabled pending interrupts even when global interrupt-enable bits are clear.
When mstatus.TW=1, lower-privilege WFI may raise an illegal-instruction exception after an implementation-specific bounded time, and may be implemented to always trap immediately.
When S-mode is implemented, U-mode WFI raises an illegal-instruction exception regardless of TW unless it completes within the implementation-specific bounded time.
If the resume event does not cause a trap, execution continues after WFI; software usually rechecks conditions and loops.
FAQ
What should software do after WFI returns?
Software should recheck its wait condition or pending state, because WFI may resume for any reason and resumption alone does not guarantee the intended event has been handled.