Reset During an Active Transfer

Chapter 15.2 stated the reset-safe rules; this chapter examines the in-flight case in detail — exactly how an active transfer behaves, signal by signal and state by state, when reset asserts. The FSM view: a master's (and slave's) transfer state machine has states — IDLE, ADDRESS phase, DATA phase, mid-burst — and reset adds a global override: from any state, asserting HRESETn forces the machine directly to IDLE, abandoning the current transfer. So reset is a transition to IDLE from every state — the FSM realization of "reset takes priority" (chapter 15.2). The crucial consequence is what happens to the data: it's not guaranteed. If reset hits during a write's data phase, the write may or may not have landed — indeterminate (don't assume it completed). If reset hits during a read, the read data is discarded (the master abandons it). A partial burst leaves only the beats done before reset; the rest are never done. So a reset-interrupted transfer has indeterminate or lost data — the operation must be treated as NOT completed and re-issued after recovery if needed. This chapter covers the FSM override, the data outcomes, and the re-issue requirement.

1. What Is It?

Reset during an active transfer is the behavior when HRESETn asserts while a transfer is in progress. Two aspects:

• The FSM override — the master/slave state machine jumps to IDLE from any state (ADDRESS, DATA, mid-burst); reset is a global transition to idle, abandoning the transfer.
• The data outcomes — write: may or may not have landed (indeterminate); read: data discarded; partial burst: only the beats done before reset completed, the rest never done.
• The consequence — the operation is NOT completed; treat it as such and re-issue after recovery if needed (don't assume completion).

So reset-during-a-transfer is the detailed, FSM-level view of chapter 15.2's "reset takes priority." At the FSM level, reset is not a normal transition (which follows the transfer flow) — it's a global override that, from whatever state the machine is in, forces it to IDLE. So the transfer is abandoned wherever it was. And because the transfer was abandoned (not completed), its data is not guaranteed — the write may not have landed, the read is discarded, the burst is partial. So the operation's outcome is indeterminate — which is why the higher level must re-issue (not assume it worked). So reset-during-a-transfer is the FSM override to idle and the resulting indeterminate data — the precise mechanics of a reset-interrupted transfer.

2. Why Does It Exist?

This behavior exists because reset's priority (chapter 15.2) means it must override the FSM regardless of state (hence the global-to-idle transition), and because abandoning the transfer mid-completion inherently leaves the data indeterminate — which forces the re-issue discipline.

The global-override FSM follows from reset priority: reset takes priority over any transfer (chapter 15.2) — and a transfer is represented by the FSM being in a non-idle state (ADDRESS, DATA, mid-burst). So for reset to override the transfer, it must force the FSM out of whatever non-idle state it's in — to IDLE. And since the FSM could be in any non-idle state when reset hits, reset must be a transition to IDLE from every state — a global override. So the global-to-idle transition exists because reset must override the transfer regardless of where the FSM is. So it's the FSM mechanics of reset priority. So reset is global-to-idle.

The indeterminate data follows from abandoning mid-completion: a transfer's data is committed at a specific point — a write lands when the slave captures it (data phase, when HREADY high); a read returns when the slave drives it. If reset abandons the transfer before that point, the data didn't commit (write not landed, read not returned). But reset could hit at or near that point — so whether the data committed is indeterminate (it depends on exactly when reset hit relative to the commit). For a write, this means it may or may not have landed (indeterminate). For a read, the master abandons the (possibly-returned) data (discarded — it doesn't use it, since the transfer was reset). For a burst, the beats before reset committed, the rest didn't (partial). So the indeterminate/lost data follows from abandoning the transfer at an arbitrary point relative to data commit. So the data is not guaranteed. So abandonment causes indeterminacy.

The reason the operation must be re-issued (not assumed complete) is the indeterminacy: since the data is indeterminate/lost, the higher level (software, or the master's controlling logic) cannot rely on the operation having completed. So it must treat the operation as NOT completed — and, if the operation needs to happen, re-issue it after recovery. Assuming completion (when the data may not have committed) would be a correctness bug (e.g. assuming a configuration write landed when it didn't). So the re-issue discipline exists because the data is indeterminate. So you re-issue. So reset-during-a-transfer behaves this way because: reset's priority forces the FSM to IDLE from any state (global override — the FSM mechanics of priority); abandoning the transfer at an arbitrary point leaves the data indeterminate (write may/may-not have landed, read discarded, burst partial — the consequence of abandonment); and the indeterminacy forces the re-issue discipline (treat as not completed, re-issue if needed — the correctness requirement). So this chapter's behavior is the detailed consequence of reset priority: the FSM override and the indeterminate data, requiring re-issue. So it's why a reset-interrupted operation must be re-done.

3. Mental Model

Model reset during a transfer as a power cut during a bank transaction at an ATM — the moment power cuts (reset), the ATM stops wherever it was (mid-PIN, mid-dispense, mid-receipt) and goes dark (FSM to idle from any state); and crucially, you don't know if your withdrawal went through — the cash may or may not have been debited (indeterminate write), the balance you were reading is gone from the screen (discarded read), and a multi-step transaction is partially done (partial burst); so when power returns, you don't assume it completed — you check and re-do it if needed (re-issue), never trusting that the interrupted transaction finished.

At an ATM (the bus), you start a transaction (a transfer). If power cuts (reset asserts), the ATM stops wherever it was — mid-PIN-entry, mid-cash-dispense, mid-receipt-printing — and goes dark, returning to its off/idle state regardless of where it was in the transaction (the FSM jumps to idle from any state). Now, the critical problem: you don't know if your transaction went through. If it cut during the withdrawal (a write), the cash may or may not have been debited from your account — indeterminate (you can't assume it did or didn't). If it cut while displaying your balance (a read), that information is gone from the screen — discarded (you don't have it). If it was a multi-step transaction (a burst — transfer, then print, then dispense), only the steps done before the cut happened; the rest didn't. So the transaction is in an uncertain, partial state. When power returns, you don't assume the withdrawal completed — you check your balance and re-do the transaction if needed (re-issue), because trusting the interrupted transaction (assuming the cash was debited, or wasn't) could be wrong either way. So: power cut stops the ATM anywhere, the transaction's outcome is uncertain, and you re-do it rather than assume.

This captures reset during a transfer: the power cut = reset asserting; the ATM stopping wherever it was and going dark = the FSM jumping to idle from any state; not knowing if the withdrawal went through = the write being indeterminate; the balance gone from the screen = the read data discarded; the multi-step transaction partially done = the partial burst; checking and re-doing = re-issuing the operation. Power cut stops anywhere, the outcome is uncertain, re-do rather than assume.

Watch reset abort a write mid-data-phase, leaving it indeterminate:

The model's lesson: power cut stops anywhere, the outcome is uncertain, re-do rather than assume. In the waveform, reset hits right at the write's capture point — so whether the write landed is indeterminate; software must re-issue rather than assume it completed.

4. Real Hardware Perspective

In hardware, the FSM-to-idle is the reset on the state flops (forcing the reset value from any state), and the data indeterminacy comes from the race between the reset and the data-commit point — making the exact outcome timing-dependent, hence indeterminate.

The FSM reset from any state: the master's/slave's state machine is implemented in flip-flops; HRESETn (asserted) forces those flops to their reset value (the IDLE-state encoding), regardless of their current value. So from any state, reset → IDLE. This is the standard reset on the state register — it overrides the next-state logic. So in hardware, the global-to-idle transition is just the reset forcing the state flops to IDLE. So it's automatic. So the FSM goes to idle by construction.

The data-commit race: whether a write landed depends on whether the slave captured HWDATA (at the data-phase clock edge, when HREADY high) before reset forced it to idle. If reset asserts just before that edge, the slave is reset before capturing — write not landed. If reset asserts just after, the slave captured — write landed. If reset asserts right at the edge — indeterminate (a race / possible metastability). Since reset (asynchronous, chapter 15.1) can assert at any time relative to the data-commit edge, the outcome is indeterminate in general. So in hardware, the write's fate is a race between reset and the capture edge — hence not guaranteed. So the indeterminacy is a real timing race. So you can't predict it.

The read discard and partial burst: for a read, even if the slave drove the data, the master is reset to idle — so it doesn't capture/use the read data (its read-data register/logic is reset, or it's in idle and ignores the bus). So the read is discarded (the master abandons it). For a burst, each beat commits at its own data-phase edge — so beats before the reset edge committed (landed/returned), beats after didn't (the burst was abandoned mid-way) — a partial burst. So in hardware, reads are discarded (master reset to idle) and bursts are partial (beats commit individually, the post-reset ones don't). So in hardware, the FSM-to-idle is the reset forcing the state flops, and the data indeterminacy is the race between reset and the data-commit edge (write: landed-or-not depending on timing; read: discarded as the master resets; burst: partial). Because reset is asynchronous and can hit anytime, the exact data outcome is timing-dependent and indeterminate — which is why the operation must be re-issued (the hardware can't guarantee the outcome). So the hardware reality: reset forces idle, the data-commit is a race, the outcome is indeterminate.

5. System Architecture Perspective

At the system level, reset-during-a-transfer's indeterminacy is why recovery software must re-establish state — it can't trust any operation in flight at the reset — and it shapes how robust recovery is designed (idempotent operations, re-initialization).

The recovery must re-establish state: because any transfer in flight at the reset has indeterminate outcome, the recovery (after a watchdog/fault reset) cannot trust the pre-reset state — any write that was in flight may or may not have landed, any read is lost. So the recovery software must re-establish the needed state from scratch (or from a known-good checkpoint) — re-initializing peripherals, re-writing configuration, not assuming any in-flight operation completed. So at the system level, the indeterminacy forces recovery to re-initialize rather than resume. So recovery is a re-establish, not a continue. So recovery software must rebuild state.

The idempotency and re-issue: for robust recovery, operations that might be re-issued (because they were in flight at a reset) should ideally be idempotent — re-doing them is safe (same result whether done once or twice). E.g. writing a configuration register is idempotent (re-writing the same value is fine); but an operation with side effects (e.g. popping a FIFO, incrementing a counter) is not idempotent — re-issuing it could double the effect. So the system must handle non-idempotent operations carefully across resets (e.g. checkpointing, or knowing whether they completed). So at the system level, the re-issue requirement interacts with idempotency — idempotent operations re-issue safely; non-idempotent ones need care. So design for safe re-issue.

The robustness and recovery design: reset-during-a-transfer is part of designing robust recovery — the system must be able to reset and recover (watchdog, fault) and come back to a correct state despite having interrupted transfers with indeterminate outcomes. This means: re-initialize on recovery (don't trust in-flight operations), use idempotent operations where possible, checkpoint critical state, and re-issue interrupted operations safely. So at the system level, reset-during-a-transfer's indeterminacy drives recovery-software design (re-establish state, don't trust in-flight operations), interacts with idempotency (idempotent ops re-issue safely; non-idempotent ones need care), and is part of building robust, recoverable systems (re-initialize, checkpoint, re-issue). So the hardware behavior (FSM-to-idle, indeterminate data) has a software/system consequence: recovery must rebuild state, treating any interrupted operation as not-completed. So reset-during-a-transfer connects the bus's reset behavior to the system's recovery architecture — a key consideration for dependable, fault-recoverable systems. So it's where reset robustness meets recovery software.

6. Engineering Tradeoffs

Reset during a transfer embodies the FSM-override, indeterminate-data, re-issue design.

• Global-to-idle override vs graceful completion. Reset forcing the FSM to idle from any state (abandoning the transfer) is simple and guarantees a clean state, at the cost of the transfer's indeterminate data. A "graceful completion" (letting the transfer finish before reset) would contradict reset's priority/immediacy. AHB uses the override.
• Indeterminate data (re-issue) vs guaranteed completion. Accepting that interrupted data is indeterminate (and re-issuing) is the realistic behavior (reset can hit anytime); guaranteeing completion is impossible (reset is async, can hit at the commit point). Re-issue.
• Idempotent operations (safe re-issue) vs non-idempotent. Idempotent operations re-issue safely after a reset; non-idempotent ones (side effects) risk double-effect on re-issue, needing care (checkpointing, completion-tracking). Prefer idempotent where re-issue is likely.
• Re-initialize on recovery vs trust pre-reset state. Recovery that re-establishes state (not trusting in-flight operations) is robust; trusting the pre-reset state risks acting on indeterminate outcomes. Re-initialize.

The throughline: when reset asserts during an active transfer, the master's and slave's FSMs jump to IDLE from any state (reset = a global transition to idle, the FSM view of "reset takes priority"), abandoning the transfer. The data is not guaranteed — a write may or may not have landed (indeterminate, a race with the commit edge), a read is discarded (the master resets to idle), a partial burst leaves only the beats done before reset. So the operation is NOT completed — treat it as such and re-issue after recovery if needed. This drives recovery software to re-establish state (don't trust in-flight operations), interacting with idempotency, as part of robust, recoverable system design.

7. Industry Example

Trace a reset hitting a configuration write and the recovery.

A watchdog reset fires while the CPU is writing a peripheral's configuration register.

• Mid-write reset. The CPU is writing CONFIG = 0x5 to a UART (a single write). It's in the data phase — HWDATA = 0x5 is being driven, the UART is about to capture it. The watchdog fires, asserting HRESETn.
• FSM to idle. The CPU master's and UART slave's FSMs are forced to idle (from the data-phase state). The write is abandoned.
• Indeterminate write. Whether the UART captured CONFIG = 0x5 is indeterminate — it depends on whether reset hit before or at the capture edge. So the UART's CONFIG might be 0x5 (if it captured) or its old/reset value (if it didn't). Software cannot know.
• Recovery (re-establish, don't trust). After the watchdog reset, the recovery firmware re-initializes the system — it does not assume the UART's CONFIG is correct. It re-writes CONFIG = 0x5 (the known-good value). Because writing CONFIG is idempotent (writing 0x5 again is fine whether or not it landed before), this is safe — the UART ends up correctly configured regardless of the interrupted write's outcome.
• A non-idempotent case (counter-example). Suppose instead the interrupted operation were popping a FIFO (a non-idempotent, side-effecting read — popping advances the read pointer). If reset hit, whether the pop happened is indeterminate. Blindly re-issuing the pop could double-pop (losing data) if the first pop did happen. So a non-idempotent operation needs care — e.g. the firmware checks the FIFO state, or the design tracks completion — so it's not double-applied. (Idempotent config writes don't have this problem.)
• Robust recovery. The firmware's discipline — re-initialize (don't trust in-flight state), re-issue idempotently (config writes) — makes the watchdog reset a reliable recovery: the system comes back correctly configured despite the interrupted write.

The example shows reset-during-a-transfer's consequence: the config write was indeterminate (might or might not have landed), so recovery re-established the state (re-wrote CONFIG, idempotently) rather than trusting it — and a non-idempotent operation (FIFO pop) would need extra care. This is how robust recovery handles reset-interrupted transfers. This is the practical reality of reset during a transfer.

8. Common Mistakes

9. Interview Insight

Reset during a transfer is a robustness interview topic — the FSM-to-idle override, the indeterminate-data outcomes, and the re-issue/re-establish requirement are the signals.

The answer that lands gives the FSM view and the data consequence: "When reset asserts during an active transfer, the master's and slave's state machines jump straight to idle from whatever state they were in — the address phase, the data phase, mid-burst. Reset is effectively a global transition to idle from every state, which is the FSM realization of reset taking priority; the transfer is abandoned wherever it was. The crucial consequence is what happens to the data: it's not guaranteed. If reset hits during a write's data phase, the write may or may not have landed in the slave — it's indeterminate, because it's a race between the reset and the slave's capture edge, and reset is asynchronous so it can hit right at that edge. If reset hits during a read, the read data is discarded — the master is reset to idle and doesn't use it. And a partial burst leaves only the beats that completed before the reset; the rest never happen. So the interrupted operation is not completed, and its outcome is uncertain. The practical rule is that software must never assume the operation completed — recovery must re-establish state, re-initializing and re-writing configuration from a known-good baseline rather than trusting any in-flight operation, and re-issuing interrupted operations, ideally idempotently so re-doing them is safe. Non-idempotent operations with side effects need extra care so they're not double-applied. So reset during a transfer means: FSM to idle, indeterminate data, re-establish and re-issue on recovery." The FSM-to-idle override, the indeterminate-data outcomes, and the re-issue/re-establish discipline are the senior signals.

10. Practice Challenge

Reason from reset during a transfer.

1. The FSM view. Explain how reset affects the transfer state machine (global transition to idle).
2. Data outcomes. State what happens to a write, a read, and a partial burst interrupted by reset.
3. Read the waveform. From Figure 2, explain why the write is indeterminate (the commit-edge race).
4. Re-establish state. Explain why recovery must re-establish state rather than trust the pre-reset state.
5. Idempotency. Explain how idempotency affects safely re-issuing interrupted operations.

11. Key Takeaways

• Reset forces the FSM to IDLE from any state — the master's/slave's state machine jumps to idle from the address phase, data phase, or mid-burst; reset is a global transition to idle (the FSM view of "reset takes priority"), abandoning the transfer.
• The data is not guaranteed — a write may or may not have landed (indeterminate — a race between the async reset and the slave's capture edge); a read is discarded (master reset to idle); a partial burst leaves only the beats done before reset.
• The operation is NOT completed — treat it as such; never assume it completed.
• Recovery must re-establish state — re-initialize and re-write configuration from a known-good baseline; don't trust any in-flight operation; re-issue what's needed.
• Re-issue idempotently where possible — idempotent operations (config writes) re-issue safely; non-idempotent ones (side effects — FIFO pop, counter) need care (completion-tracking) to avoid double-application.
• It connects to recovery architecture — the hardware can't tell you if the interrupted operation completed (a race), so software must be designed to not need to know — re-establish state, treating reset as a clean slate. Foundational to fault-recoverable design.

12. What Comes Next

You now understand reset during an active transfer — the FSM override to idle, the indeterminate data, and the re-establish/re-issue recovery discipline. With HRESETn's semantics (15.1) and the reset-safe rules (15.2), you have the reset picture. The next chapters turn to clocking:

• Clock Gating Considerations (next) — safe HCLK gating without corrupting transfers.
• Low-Power Implications, CDC Bridges — AHB activity and power, and crossing asynchronous clock domains.

To revisit the reset rules this details, see Reset-Safe Transfers and HRESETn Behavior.