Reset-Safe Transfers

Chapter 15.1 covered HRESETn's semantics; this chapter states the rules that keep transfers safe around reset — how the bus behaves correctly when reset interacts with transfers. Four rules. (1) Reset takes priority — an asserted reset overrides any in-flight transfer; masters and slaves abandon what they were doing and go to the reset idle state (reset is the highest-priority condition). (2) Both sides reset together — master and slave see the same HRESETn, so they leave reset in step (consistent — no side ahead of the other). (3) Restart cleanly from idle — on reset exit, the master starts from the reset idle state with a fresh transfer (IDLE first, or a fresh NONSEQ), never resuming a transfer that reset interrupted (its state was discarded by reset — resuming would use stale/undefined address/control). (4) Only HRESETn is asynchronous — every other signal stays synchronous, so there's no surprise async behavior mid-transfer. This chapter states these reset-safe rules and why each matters for correct operation around reset.

1. What Is It?

Reset-safe transfers are AHB transfers that behave correctly when reset interacts with them. The rules:

• Reset takes priority — an asserted reset overrides any in-flight transfer; masters/slaves abandon it and go to idle.
• Both sides reset together — master and slave share HRESETn, so they leave reset in step (consistent).
• Restart cleanly from idle — on exit, the master issues a fresh transfer from idle (IDLE / fresh NONSEQ); it never resumes an interrupted transfer.
• Only HRESETn is async — all other signals are synchronous; no surprise async mid-transfer behavior.

So reset-safe transfers are about correctly handling the boundary between reset and normal operation — ensuring that when reset asserts (interrupting whatever's happening) and deasserts (resuming operation), the bus stays consistent and defined. The rules ensure: reset wins (overrides in-flight transfers — no half-completed transfer lingers), both sides agree (master and slave reset together — neither is left in a stale state), and the restart is clean (a fresh transfer from idle — no resuming a corrupted/discarded transfer). So reset-safe transfers are the disciplined handling of reset's interaction with transfers — keeping the bus correct across the reset boundary. So they're the rules for safe reset-transfer interaction.

2. Why Does It Exist?

The reset-safe rules exist because reset can assert at any time — including mid-transfer — and the bus must remain consistent and recoverable across that interruption: reset must win (no lingering half-transfer), both sides must agree (no stale state), and the restart must be clean (no resuming corrupted state).

The reset-can-interrupt-anything is the root: reset asserts asynchronously and at any time (chapter 15.1) — including in the middle of a transfer (the address phase, the data phase, mid-burst). So the bus will face reset interrupting transfers. The rules exist to handle this correctly — to define what happens when reset hits an in-flight transfer and how to recover. So reset-safe rules exist because reset can and will interrupt transfers, and the bus needs defined, safe behavior. So they handle the mid-transfer reset.

The reset-takes-priority rule prevents lingering state: when reset interrupts a transfer, the transfer is abandoned — it does not complete, and its state is discarded. Reset overrides it (reset is the highest-priority condition). If reset didn't take priority (e.g. a transfer "finished" despite reset), there'd be inconsistent state — a transfer half-done, the bus in a confused condition. So reset wins: the transfer is abandoned, everything goes to the clean idle. So the priority rule exists to ensure no lingering half-transfer — reset forces a clean slate. So reset overrides.

The both-sides-reset-together rule prevents inconsistency: master and slave both see HRESETn (it's global, chapter 15.1), so they both reset, together. If only one reset (or they reset at different times), they'd disagree — e.g. the master thinks a transfer is done but the slave is mid-transfer, or one is in reset and the other isn't — inconsistent, corrupt. So both reset in step (same HRESETn, synchronous deassert from 15.1 → coherent release). So the together rule exists to keep master and slave consistent across reset. So both agree.

The restart-cleanly-from-idle rule prevents corrupt resumption: after reset, the interrupted transfer's state was discarded (rule 1). So resuming it would use stale/undefined address/control (the discarded state) — corrupting the access (accessing a garbage address, etc.). So the master must not resume the interrupted transfer — it must start fresh from the reset idle state (a new NONSEQ with a fresh address). So the clean-restart rule exists to prevent corrupt resumption — always begin anew. So restart fresh. So the reset-safe rules exist because reset can interrupt transfers at any time (the why), and the bus must stay consistent and recoverable: reset takes priority (no lingering half-transfer — abandon and go idle), both sides reset together (no inconsistency — master/slave in step via shared HRESETn), and the master restarts cleanly from idle (no corrupt resumption — the interrupted transfer's state is gone, so begin anew). Plus only HRESETn is async (so apart from reset, behavior stays synchronous and predictable). So the rules collectively ensure the bus survives a reset correctly — abandoning the interrupted transfer cleanly, both sides agreeing, and restarting fresh. So this chapter's rules are the discipline for safe reset-transfer interaction.

3. Mental Model

Model reset-safe transfers as a building's fire alarm protocol — when the alarm sounds (reset asserts), everyone stops whatever they're doing and evacuates to the assembly point (reset idle), no matter how important their task (reset takes priority); everyone hears the same alarm and evacuates together (both sides reset together — no one left behind mid-task); and when the all-clear sounds, people don't try to resume the exact half-finished task they abandoned (the papers are scattered, the state is lost) — they start fresh from a clean state (restart from idle, never resume the interrupted task).

A building (the AHB bus) has a fire alarm protocol for safety. When the alarm sounds (reset asserts), everyone — regardless of how important their current task — immediately stops and evacuates to the assembly point (the reset idle state). The alarm takes priority over everything; you don't finish your meeting first (reset overrides any in-flight transfer). Crucially, everyone hears the same alarm and evacuates together (both sides — master and slave — share HRESETn and reset in step); no one is left behind mid-task while others evacuate (no inconsistency). And when the all-clear sounds (reset deasserts), people don't return to their desks and try to resume the exact half-finished task they abandoned — the papers are scattered, the half-done work is lost/invalid (the interrupted transfer's state was discarded). Instead, they start fresh from a clean state — re-begin work anew (the master restarts from idle with a fresh transfer). Trying to resume the abandoned task from its lost state would be chaotic and wrong (corrupt). So: alarm overrides everything, everyone evacuates together, and work restarts fresh from a clean state — never resuming the abandoned task.

This captures reset-safe transfers: the fire alarm = HRESETn assert; everyone stopping regardless of task = reset taking priority over any transfer; the assembly point = the reset idle state; everyone hearing the same alarm and evacuating together = both sides reset together (shared HRESETn); no one left behind mid-task = no master/slave inconsistency; the all-clear = reset deassert; not resuming the half-finished task = not resuming the interrupted transfer; starting fresh from a clean state = the master restarting from idle. Alarm overrides, evacuate together, restart fresh — never resume the abandoned task.

Watch reset abort a transfer and the master restart from idle:

The model's lesson: alarm overrides, evacuate together, restart fresh — never resume the abandoned task. In the waveform, reset abandons the transfer to A (bus → idle), and on release the master starts a fresh transfer to B — not resuming the aborted A.

4. Real Hardware Perspective

In hardware, the reset-safe rules are enforced by the reset priority in the masters'/slaves' logic, the shared HRESETn distribution, and the masters' state machines resetting to idle (so they can't resume an interrupted transfer — they're in idle).

The reset priority in the logic: each master's and slave's state machine has reset as the highest-priority input — when HRESETn is asserted, the FSM goes to its reset (idle) state, overriding whatever transfer it was doing. This is the standard synchronous (or async) reset on the state flops: reset forces the reset value, regardless of the other logic. So in hardware, reset priority is the reset's override of the FSM state. So the in-flight transfer is abandoned because the FSM is forced to idle. So reset wins by construction.

The shared HRESETn distribution: HRESETn is a global signal to all masters and slaves (chapter 15.1). So they all reset together — no master resets while a slave doesn't. And with synchronous deassertion (chapter 15.1), they all leave reset on the same edge — coherent. So in hardware, the shared, synchronously-released HRESETn ensures master and slave reset in step. So both sides agree by sharing the reset. So consistency is structural.

The reset-to-idle prevents resumption: because the master's FSM resets to idle, after reset it's in the idle state — it has no memory of the interrupted transfer (its state was reset). So it can't resume it — it can only start a fresh transfer from idle (the FSM's normal idle→active path, with a fresh address). So in hardware, the reset-to-idle structurally prevents corrupt resumption — there's no "resume" path because the state is gone. So a correctly-designed master automatically restarts cleanly (it's in idle, with no stale transfer state). The bug would be a master that retained some transfer state across reset (not fully reset) and tried to use it — so the rule is: fully reset the master's transfer state so it can only start fresh. So in hardware, the reset-safe rules are enforced by reset priority (FSM forced to idle, abandoning the transfer), shared synchronously-released HRESETn (both sides reset in step), and full reset-to-idle (no retained transfer state → can only restart fresh). So a properly-reset master/slave is reset-safe by construction. So the hardware reality: reset all transfer state to idle, share the reset, and the rules hold.

5. System Architecture Perspective

At the system level, the reset-safe rules ensure the bus is robust across resets — system resets, subsystem resets, recovery resets — so that a reset cleanly recovers the bus to a known state without leaving it corrupt, which is essential for reliable recovery and fault handling.

The clean recovery: resets happen not just at power-up but for recovery — a watchdog timeout, a fault, a software-triggered reset of a subsystem. The reset-safe rules ensure that whenever reset asserts (even mid-transfer), the bus cleanly recovers to the known idle state and restarts correctly — no lingering corruption from the interrupted transfer. So a reset is a reliable recovery mechanism — it always brings the bus to a clean state. So at the system level, the reset-safe rules make reset a dependable recovery tool — critical for fault tolerance (reset to recover from a hang/fault). So reset reliably recovers.

The subsystem reset domains: SoCs often have multiple reset domains — different subsystems can be reset independently (e.g. reset a peripheral without resetting the CPU). For the bus to be reset-safe across domain boundaries, the rules must hold at the boundary: if a slave's domain resets but the master's doesn't, the master must handle the slave's reset gracefully (the slave abandons its transfer; the master sees it, e.g. via a timeout or error). So the reset-safe rules extend to partial resets — and the system must ensure that a reset of one domain doesn't corrupt another (e.g. leave the master hung waiting on a reset slave). So at the system level, reset-safety must be considered per reset domain — a partial reset is safe only if the boundary is handled (often the master must tolerate the reset slave). So multi-domain reset needs care. (Full-system reset, where everything resets together, is the simplest reset-safe case.)

The robustness foundation: the reset-safe rules are part of the bus's robustness — alongside the illegal-address/default-slave behavior (Module 11) and the response handling — they ensure the bus survives abnormal events (resets, faults) in a defined way. A bus that wasn't reset-safe (corrupted state after a mid-transfer reset) would be fragile — a reset (a common recovery action) could break it. So reset-safety is a robustness requirement. So at the system level, the reset-safe rules ensure clean, reliable recovery (reset always brings the bus to a known state — critical for fault handling), must be considered per reset domain (partial resets are safe only if the boundary is handled — the master tolerating a reset slave), and are part of the bus's overall robustness (surviving abnormal events in a defined way). So reset-safety is what makes reset a trustworthy recovery mechanism and the bus robust against the resets that inevitably occur. So it's foundational to a dependable system.

6. Engineering Tradeoffs

Reset-safe transfers embody the reset-overrides, reset-together, restart-fresh discipline.

• Reset overrides vs transfer completes. Reset taking priority (abandoning the in-flight transfer) ensures a clean slate; letting a transfer "complete" despite reset would leave inconsistent state. Reset must override.
• Both reset together vs independent. Master and slave resetting together (shared HRESETn) keeps them consistent; independent/staggered reset risks disagreement (one mid-transfer, one reset). For a domain, share the reset.
• Restart fresh vs resume. Restarting from idle with a fresh transfer is clean (the interrupted state is gone); resuming the interrupted transfer would use stale/undefined state (corruption). Always restart fresh.
• Full-system reset (simple) vs multi-domain (flexible). A full reset (everything together) is simplest and trivially reset-safe; multi-domain resets (subsystem-independent) are flexible but require handling the boundary (the master tolerating a reset slave). Use multi-domain with care.

The throughline: reset-safe transfers follow four rules — reset takes priority (overrides any in-flight transfer → abandon it, go to idle); both sides reset together (shared HRESETn → master and slave leave reset in step); restart cleanly from idle (on exit, a fresh transfer — never resume the interrupted one, whose state was discarded); and only HRESETn is asynchronous (everything else synchronous). They ensure the bus stays consistent and recoverable across a reset (even mid-transfer) — abandoning the interrupted transfer cleanly, both sides agreeing, restarting fresh. In hardware, they're enforced by reset priority (FSM forced to idle), shared synchronously-released HRESETn, and full reset-to-idle. They make reset a reliable recovery mechanism and the bus robust against the resets that inevitably occur.

7. Industry Example

Trace a reset interrupting a transfer and the clean recovery.

A system experiences a watchdog reset while the CPU is mid-burst to memory.

• Mid-transfer reset. The CPU is executing an INCR4 burst to SRAM — say, 2 of 4 beats done. A watchdog timer fires (the CPU hung elsewhere), asserting HRESETn (a recovery reset).
• Reset takes priority. HRESETn (asserted, asynchronously) overrides the burst — the CPU master's FSM and the SRAM slave's FSM are forced to their reset idle state. The burst is abandoned mid-way — beats 3 and 4 are not done, and the burst's state is discarded. The bus goes to the clean idle (HTRANS=IDLE, HREADY=1, HRESP=OKAY).
• Both reset together. Both the CPU master and the SRAM slave see the same HRESETn — they reset together. So there's no inconsistency (e.g. the master thinking the burst continues while the slave is reset). They're in step.
• Synchronous release. Once the system stabilizes, HRESETn deasserts synchronously (chapter 15.1) — both sides leave reset on the same edge, coherently.
• Clean restart (not resume). The CPU does not try to resume the abandoned burst (its state is gone — beats 3-4's addresses, the burst context, all discarded). Instead, the CPU restarts fresh — it begins executing from the reset vector (a fresh instruction fetch), as at power-up. The abandoned burst is simply lost (the watchdog reset is a recovery — the prior operation is discarded; software re-initializes).
• The resume bug (counter-example). Had the CPU (or its bus interface) tried to resume the abandoned burst (using stale beat-3 address state that was partially reset), it could have accessed a garbage address or driven inconsistent control — corrupting memory or hanging. The reset-to-idle design prevents this: the CPU is in idle, with no burst state, so it can only start fresh.

The example shows the reset-safe rules in a recovery scenario: the watchdog reset overrides the mid-burst transfer (abandoning it), both sides reset together (consistent), and the CPU restarts fresh from the reset vector (not resuming the abandoned burst). The clean recovery — reset to a known state, restart fresh — is exactly what makes the watchdog a reliable recovery mechanism. This is reset-safe transfer behavior in practice.

8. Common Mistakes

9. Interview Insight

Reset-safe transfers is a robustness interview topic — the reset-overrides, reset-together, restart-fresh rules (and the never-resume point) are the signals.

The answer that lands states the rules with the never-resume emphasis: "There are a few rules that keep transfers safe around reset. First, reset takes priority: an asserted reset overrides any in-flight transfer — the masters and slaves abandon whatever they were doing and go to the reset idle state. Reset is the highest-priority condition, so a transfer in progress doesn't complete; it's abandoned. Second, both sides reset together: the master and slave see the same HRESETn — it's a global signal — so they leave reset in step, staying consistent; you never have the master thinking a transfer continues while the slave is reset. Third, and most important: the master must restart cleanly from idle — on reset exit, it issues a fresh transfer, a new NONSEQ with a fresh address, exactly as at power-up. It must never resume the transfer that reset interrupted, because reset discarded that transfer's state — the address, the burst progress, all reset — so resuming would use stale or undefined values and corrupt the access. So the interrupted transfer is simply lost, and the master begins anew. In hardware, this is automatic if the master is fully reset to idle: with no retained transfer state, it can only start fresh. And only HRESETn is asynchronous; everything else stays synchronous. These rules make reset a reliable recovery mechanism — a watchdog or fault reset always brings the bus cleanly to a known state and restarts correctly, even if it hit mid-transfer." The reset-overrides, reset-together, and never-resume (restart-fresh) rules are the senior signals.

10. Practice Challenge

Reason from reset-safe transfers.

1. The rules. State the four reset-safe rules.
2. Reset priority. Explain what happens to an in-flight transfer when reset asserts.
3. Read the waveform. From Figure 2, explain how reset abandons the transfer and why the master starts a fresh (not resumed) transfer.
4. Reset together. Explain why master and slave must reset together and what goes wrong otherwise.
5. Never resume. Explain why the master must never resume an interrupted transfer.

11. Key Takeaways

• Reset takes priority — an asserted reset overrides any in-flight transfer; masters and slaves abandon it and go to the reset idle state. A transfer in progress does not complete.
• Both sides reset together — master and slave share HRESETn (global, synchronously released), so they leave reset in step (consistent); neither is left in a stale state.
• Restart cleanly from idle — on reset exit, the master issues a fresh transfer (a new NONSEQ with a fresh address), never resuming the interrupted transfer (whose state was discarded — resuming would use stale/undefined values → corruption).
• Only HRESETn is asynchronous — every other signal stays synchronous; no surprise async behavior mid-transfer.
• In hardware: enforced by reset priority (FSM forced to idle), shared synchronously-released HRESETn (in step), and full reset-to-idle (no retained transfer state → resumption impossible by construction).
• Reset is a reliable recovery mechanism — the rules ensure a clean recovery to a known state even mid-transfer (watchdog/fault resets), making reset trustworthy and the bus robust; multi-domain resets need boundary handling.

12. What Comes Next

You now understand the reset-safe rules — reset overrides, both reset together, restart fresh. The next chapter examines the in-flight case in more detail:

• Reset During an Active Transfer (next) — how an in-flight transfer behaves, signal by signal, when reset asserts (the FSM view).
• Clock Gating, Low-Power Implications, CDC Bridges — safe clock gating, power, and crossing clock domains.

To revisit HRESETn's semantics, see HRESETn Behavior; for the idle state reset returns to, see HTRANS & Bus Control.