ERROR Response

Chapter 7.1 covered OKAY — the silent default success. This chapter covers the response that matters when things go wrong: ERROR. ERROR is the HRESP value a subordinate drives when it cannot complete a transfer successfully — an unmapped address, a permission violation, an internal fault, an unsupported access. Two things make ERROR worth a dedicated chapter (and its Critical rating). First, it is a mandatory two-cycle response — unlike single-cycle OKAY, ERROR is signaled across two cycles to give the manager a guaranteed cycle to react. Second, ERROR reports a failure but does not automatically undo anything — it tells the manager "this didn't work," and the manager decides how to recover. Understanding both is essential to handling failures correctly.

1. What Is It?

ERROR is the HRESP value meaning the subordinate could not complete the transfer successfully — it is the failure outcome, the counterpart to OKAY's success.

A subordinate drives ERROR when something prevents a successful transfer. The common triggers:

• Unmapped address — no real subordinate exists at that address; the default subordinate (chapter 3.10) returns ERROR.
• Permission / security violation — the access is not allowed by privilege (HPROT) or security (HNONSEC) rules.
• Subordinate-internal fault — the subordinate itself cannot complete (e.g., an ECC failure, a hardware fault).
• Unsupported / illegal access — a size, alignment, or burst the subordinate does not support, or a locked/protected region.

ERROR is fundamentally informational: it reports that the transfer failed. It is not an automatic recovery mechanism — it does not undo a write, retry the transfer, or roll back state. It simply signals the failure to the manager, which then decides what to do (raise an exception, abort a burst, log a fault, etc., chapter 7.7). So ERROR's job is to report, not to fix. This reporting-not-fixing nature is central to using ERROR correctly.

2. Why Does It Exist?

ERROR exists because transfers can fail, and the manager must be told when one does — without a failure signal, a manager would treat a failed transfer as if it succeeded (consuming garbage read data, assuming a rejected write happened). ERROR is the explicit "this didn't work" that prevents that.

Consider a read of an unmapped address. Without an error mechanism, what would happen? The transfer would have to complete somehow (the bus can't hang, chapter 6.7), returning some data — which the manager would consume as if valid, silently using garbage. That is a dangerous silent failure. ERROR exists to make the failure explicit: the default subordinate returns ERROR, so the manager knows the read failed and can handle it (raise a fault) rather than trusting garbage. So ERROR exists to turn silent failures into reported failures — to ensure the manager learns when a transfer didn't do what it was asked. This is essential for correctness and security (an unmapped or unauthorized access must not silently appear to succeed).

The reason ERROR is a two-cycle response (rather than single-cycle like OKAY) is the pipeline: by the time a subordinate signals an error in a transfer's data phase, the manager has already pipelined the next transfer's address phase (chapter 5.1). If the error completed in a single cycle, the manager would have no clean opportunity to stop that next transfer before it committed. The two-cycle response gives the manager a guaranteed cycle to react: the first cycle (HREADY low) is a warning — "an error is coming" — during which the manager can cancel the already-pipelined next transfer (drive it to IDLE); the second cycle (HREADY high) completes the errored transfer. So the two cycles exist to solve the pipeline problem: they give the manager time to react before the error completes and before the next transfer proceeds. (Chapter 7.6 details this timing.)

The reason ERROR reports rather than fixes (doesn't auto-undo a write) is that recovery is a policy decision the manager owns, not something the bus can do generically. What should happen on a failed write? Retry? Abort the burst? Raise an exception? Log and continue? The answer depends on the system and the situation — only the manager (and its software) can decide. So the bus's job is to report the failure accurately; the response to it is the manager's policy. If ERROR tried to auto-undo, it would impose one recovery policy on everyone, which wouldn't fit all cases. So ERROR reports and leaves recovery to the manager — separating mechanism (report the failure) from policy (decide what to do).

3. Mental Model

Model ERROR as a transaction being declined at a register — the clerk says "this won't go through" (and gives you a heads-up first), but declining doesn't reverse anything else; you decide what to do next.

At a checkout (the bus), you try to pay (a transfer). Sometimes it's declined (ERROR) — the card's not valid here (unmapped address), it's over-limit or not authorized (permission violation), the terminal faults (internal error), or the payment type isn't supported (unsupported access). The clerk gives you a heads-up — "this is going to decline" (the first warning cycle) — and then it declines (the completing cycle). Crucially, declining doesn't undo your other actions — it doesn't refund a previous purchase or fix anything; it just tells you this payment failed. What you do next — try another card, cancel the order, call the bank — is your decision (the manager's recovery policy). The clerk reports; you decide.

This captures ERROR: the decline = the failure outcome; the heads-up then decline = the two-cycle warning-then-completion; declining doesn't undo other things = ERROR reports without auto-rollback; you decide what's next = the manager owns recovery. The decline is informational — it tells you the payment didn't work, no more.

Watch the two-cycle ERROR response:

The model's lesson: ERROR is a decline with a heads-up — the warning cycle (HREADY low) lets the manager react before the decline completes (HREADY high). In the waveform, HRESP=ERROR spans two cycles; the first (HREADY low) is the warning, the second (HREADY high) completes the failed transfer. The decline reports; recovery is the manager's.

4. Real Hardware Perspective

In hardware, ERROR is driven by the data-phase subordinate on HRESP (aggregated like HREADY/OKAY, chapter 6.6), and the two-cycle behaviour is a specific HREADY/HRESP sequence the subordinate produces.

The subordinate detects the error condition (its address decode found no match — for the default subordinate; its permission check failed; its internal logic faulted; the access is unsupported) and, instead of completing OKAY, produces the two-cycle ERROR sequence. In hardware this is a small state machine: on detecting an error in the data phase, drive HRESP=ERROR with HREADY=0 for one cycle (the warning), then HRESP=ERROR with HREADY=1 for one cycle (completion). The HREADY-low first cycle is what extends the response to two cycles; the HREADY-high second cycle completes it. So the two-cycle ERROR is a defined HREADY/HRESP waveform the subordinate generates — not a separate signal, just a specific sequence on the existing response/timing signals (chapter 7.6 details it).

The default subordinate is the hardware that handles the most common ERROR trigger — unmapped addresses (chapter 3.10). When the decoder finds no real subordinate for an address, it selects the default subordinate, whose entire job is to return the two-cycle ERROR (and, for the bus's sake, to always complete so the bus doesn't hang). So the default subordinate is, in effect, a dedicated ERROR generator for unmapped space. This is why an unmapped access produces a clean ERROR rather than a hang: the default subordinate is there to respond. In hardware, every AHB system has this default-subordinate ERROR path.

The HRESP encoding depends on version (chapter 7.1): in full AHB, HRESP is 2-bit (ERROR is one of OKAY/ERROR/RETRY/SPLIT); in AHB-Lite/AHB5, HRESP is effectively 1-bit (OKAY/ERROR only). So in the simplified versions, ERROR is the failure response (no RETRY/SPLIT). This chapter's ERROR behaviour — the two-cycle response, the triggers — is the same across versions; only the set of other responses differs. ERROR is universal; RETRY/SPLIT are the full-AHB-only legacy additions (chapters 7.3/7.4).

A crucial hardware/semantic point: ERROR does not define what happens to a write's side effects. Whether a write that errored actually modified any state is implementation-specific — the protocol only says the transfer failed, not whether it was atomic or partially applied. So a manager (and software) must not assume an errored write either definitely happened or definitely didn't — it must treat the state as uncertain and recover according to policy. In hardware, the subordinate may or may not have applied a partial effect before erroring; ERROR doesn't specify. This is why ERROR is "report, not fix" — it makes no guarantee about rollback, so recovery must be explicit.

5. System Architecture Perspective

At the system level, ERROR is the foundation of fault detection and security enforcement — it is how the bus surfaces illegal, unauthorized, and failed accesses to the manager and ultimately to software, enabling exceptions, protection, and robust error handling.

ERROR underpins memory protection and security: when an access violates privilege (HPROT) or security (HNONSEC) rules, the subordinate (or a protection unit) returns ERROR, which the manager turns into a fault/exception (chapter 7.7). So ERROR is the mechanism by which unauthorized accesses are blocked and reported rather than silently allowed — a security-critical function. A TrustZone-style secure system relies on ERROR to deny non-secure accesses to secure regions (chapter on HNONSEC). So at the system level, ERROR is not just "a failed transfer" but the enforcement signal for the system's protection and security policies. Without ERROR, illegal accesses couldn't be cleanly denied and reported.

ERROR also underpins fault detection and reporting: an unmapped access (software bug — a wild pointer), a hardware fault (ECC failure), or an unsupported access all surface as ERROR, which the manager escalates to a processor exception or fault handler. So ERROR is how the system detects and responds to faults at the bus level — it is the bus's contribution to the system's fault-handling architecture. A robust system uses ERROR to catch and contain faults (a wild access faults rather than silently corrupting); the processor's exception handler then logs, recovers, or terminates the offending software. ERROR is thus the bus-level entry point to the whole fault-handling stack.

The report-not-fix design is architecturally important because it keeps recovery policy where it belongs — in the manager and software — while the bus provides only the mechanism (accurate failure reporting). This separation lets different systems implement different recovery policies (retry, abort, fault, ignore) on the same bus mechanism. So the architecture cleanly divides: the bus reports failures (ERROR), and the system decides recovery (in the manager/software). This is the right separation — the bus can't know the right recovery for every situation, so it reports accurately and lets the policy layer decide. It is the same mechanism-vs-policy separation that good architectures use throughout.

A subtlety for bursts: an ERROR in the middle of a burst typically requires the manager to decide whether to continue or abort the remaining beats (chapter 7.7, and the burst chapters of Module 8). The two-cycle ERROR's reaction window is what lets the manager cleanly abort the rest of the burst (drive IDLE) rather than blindly continuing into more failing beats. So ERROR's interaction with bursts is a system-level concern: a single errored beat may invalidate the burst, and the manager must handle that. This is one reason the manager's reaction window (the two-cycle design) matters — it enables clean burst abort on error.

6. Engineering Tradeoffs

ERROR's design reflects AHB's report-the-failure, manager-decides choice.

• Two-cycle ERROR vs single-cycle. The two-cycle response gives the manager a guaranteed reaction cycle (to cancel the pipelined next transfer) at the cost of one extra cycle on the rare error. A single-cycle error would be faster but leave the manager no clean window to stop the next transfer in the pipeline. AHB chooses two-cycle — the reaction window is worth one cycle on a rare event.
• Report vs auto-recover. ERROR reports the failure and leaves recovery to the manager, keeping the bus simple and recovery-policy flexible, at the cost that the manager must implement handling. Auto-recovery (e.g., automatic retry) would offload the manager but impose one policy. AHB reports and delegates — mechanism vs policy separation.
• No write-rollback guarantee vs atomic errors. ERROR makes no guarantee about an errored write's side effects (implementation-specific), keeping subordinates simple, at the cost that recovery must treat state as uncertain. Guaranteeing atomicity (full rollback) would burden every subordinate. AHB leaves it unspecified — simplicity over a strong atomicity guarantee.
• Universal ERROR vs richer failure set. ERROR is the universal failure response (all versions); full AHB adds RETRY/SPLIT for specific cases (chapters 7.3/7.4), but AHB-Lite/AHB5 drop those, keeping just OKAY/ERROR. The trade is expressiveness vs simplicity; the modern trend (AHB-Lite/AHB5) favors the simple OKAY/ERROR set, with ERROR as the sole failure.

The throughline: ERROR is a two-cycle, report-not-fix failure response that surfaces faults and enforces protection, leaving recovery to the manager. The costs (an extra cycle on errors, manager-implemented recovery, uncertain write state) are accepted because they keep the bus simple, the recovery policy flexible, and the reaction window available — the right trade-offs for a failure mechanism that must be accurate but not prescriptive.

7. Industry Example

Trace ERROR across several failure scenarios in a system.

A processor with a memory-protection scheme accesses a system with mapped memory, peripherals, and unmapped regions.

• Wild pointer — unmapped address ERROR. Buggy software dereferences a wild pointer into unmapped address space. The decoder finds no subordinate; the default subordinate returns the two-cycle ERROR. The processor receives ERROR, raises a bus-fault exception, and its handler logs the fault and terminates the offending task — rather than silently reading garbage. ERROR caught the bug.
• Unauthorized access — permission ERROR. Non-secure software tries to read a secure peripheral. The protection logic detects the violation (HNONSEC/HPROT) and returns ERROR. The processor faults; the security monitor handles it (logs the violation, denies access). ERROR enforced the security boundary — the secure data was never returned.
• ECC failure — subordinate-internal ERROR. A read hits a memory location with an uncorrectable ECC error. The memory subordinate, unable to return valid data, returns ERROR. The processor faults; the handler may retry, mark the page bad, or escalate. ERROR surfaced the hardware fault instead of returning corrupt data.
• Unsupported access — access ERROR. Software issues an unaligned access to a subordinate that requires alignment. The subordinate returns ERROR. The processor faults; the handler corrects or reports the misuse. ERROR caught the illegal access.
• The reaction window in a burst. A burst write hits an error on its third beat. The two-cycle ERROR gives the processor a cycle to react: it drives the next (already-pipelined) beat to IDLE, aborting the rest of the burst cleanly, then handles the error — rather than blindly writing the remaining beats into a failing region. The reaction window enabled the clean abort.
• Recovery is the processor's policy. In every case, ERROR reported the failure; the recovery (fault handler action — log, retry, terminate, deny) was the processor/software's decision. The bus did its job (accurate reporting); the system did its job (policy-based recovery). And after the errored write, software treated the target state as uncertain, re-establishing known state where needed.

The example shows ERROR as the system's fault-and-security backbone: it catches wild pointers, enforces protection, surfaces hardware faults, and flags illegal accesses — each reported accurately via the two-cycle response, each handled by the manager's policy. The reaction window enabled clean burst abort, and recovery remained the manager's decision throughout. ERROR is how failures become handled rather than silent.

8. Common Mistakes

9. Interview Insight

ERROR is a frequent, Critical-rated interview topic — it tests the two-cycle handshake and the report-not-fix semantics.

The answer that lands covers meaning, timing, and semantics: "ERROR is the HRESP value meaning the subordinate couldn't complete the transfer — from an unmapped address (the default subordinate responds), a permission or security violation, an internal fault, or an unsupported access. It's a mandatory two-cycle response: the first cycle drives ERROR with HREADY low — a warning — and the second drives ERROR with HREADY high to complete. The two cycles exist because the next transfer is already pipelined, so the manager needs a guaranteed cycle to react — for instance, to drive the next transfer to IDLE and cancel it. And ERROR reports the failure; it doesn't automatically undo a write — whether an errored write partially applied is unspecified, so the manager treats the state as uncertain and recovery is its policy decision." The two-cycle rationale and the report-not-fix point are the senior signals.

10. Practice Challenge

Reason from ERROR's meaning, timing, and semantics.

1. List the triggers. Name the four common causes of an ERROR response.
2. Read the waveform. From Figure 2, identify the warning cycle and the completion cycle, and what HREADY does in each.
3. Explain the two cycles. Why does ERROR need two cycles? Tie it to the pipeline.
4. Report not fix. Explain why ERROR doesn't undo a write and how a manager should treat the state afterward.
5. System role. Explain how ERROR underpins fault detection and security enforcement.

11. Key Takeaways

• ERROR is the HRESP failure outcome — the subordinate couldn't complete the transfer (unmapped address, permission/security violation, internal fault, or unsupported access).
• ERROR is a mandatory two-cycle response: cycle 1 = ERROR with HREADY low (warning), cycle 2 = ERROR with HREADY high (completion). The two cycles give the manager a guaranteed reaction window.
• The two cycles exist because of the pipeline — the next transfer is already issued, so the manager needs a cycle to react (e.g., drive the next transfer to IDLE) before the error completes.
• ERROR reports, it doesn't fix — it makes no guarantee about a write's side effects (implementation-specific), so the manager treats the state as uncertain and owns recovery policy.
• The default subordinate returns ERROR for unmapped addresses — the most common ERROR source — preventing silent garbage reads and bus hangs.
• ERROR is the foundation of fault detection and security enforcement — illegal, unauthorized, and failed accesses surface as ERROR and become exceptions; the bus provides the mechanism, the system the policy.

12. What Comes Next

You now understand the success (OKAY) and failure (ERROR) responses. The next chapters cover the legacy responses and the timing/handling details:

• 7.3 / 7.4 — RETRY & SPLIT (coming next) — the legacy full-AHB responses for slow subordinates that free the bus, and why AHB-Lite/AHB5 dropped them.
• 7.5 / 7.6 (coming soon) — response timing and the detailed two-cycle ERROR handshake.
• 7.7 — How the Master Reacts (coming soon) — the manager's handling of each response type.

To revisit the success case, see OKAY Response. For the default subordinate that returns ERROR on unmapped addresses, see HSEL and Master, Slave, Decoder & Arbiter. For the reaction window's interaction with the pipeline, see The Two-Phase Pipeline. For the broader protocol map, see the AMBA family overview.