I²C 7-bit & 10-bit Addressing + Multi-Master Arbitration
← Back to: I²C / SPI / UART — Serial Peripheral Buses
This page explains how I²C 7-bit/10-bit addressing and multi-master arbitration really behave on the wire, and how to prevent/diagnose conflicts, bus-stalls, and recovery races with measurable rules. The goal is predictable bus ownership and repeatable bring-up/production checks—without expanding into pull-up, stretching, or SI topics.
Scope & boundary: what this page solves (and what it must not)
Intent
Establish a hard boundary so every paragraph stays vertical: this page is about I²C addressing behavior and multi-master concurrency (arbitration, ownership, sync, recovery). Anything dominated by waveform/edge/cable physics is redirected to sibling pages.
Covers (in-scope)
- 7-bit & 10-bit addressing: encoding, transaction sequences, where ACK/NACK is meaningful, and capability mismatches.
- Multi-master arbitration: what “0 beats 1” implies, where arbitration can be lost, and how winners/losers must behave.
- Clock synchronization (multi-master view): timing based on real bus edges, and how timeout policy must follow actual SCL behavior.
- Conflict & bus-stall recovery (multi-master view): ownership rules, preventing “double recovery”, safe probe transactions, and re-entry.
- Firmware state machines & verification hooks: ALOST handling, backoff design, counters/log fields, analyzer triggers, and pass criteria placeholders.
Must NOT cover (out-of-scope)
- Pull-up/RC/tR/tF math, rise-time compliance, edge shaping, and pull-up power accounting.
- Clock stretching as a full tutorial (this page only mentions it when multi-master policies could mis-classify it).
- Long-trace/cable SI & EMC: reflections, CMC sizing, shielding, ESD/surge deep dives, and cable health monitoring details.
- I³C HDR deep mode details (this page keeps only a compatibility warning where legacy devices can hang a mixed bus).
Boundary classifier (fast decision rule)
If the dominant cause is address encoding / ownership / arbitration / retry logic → in-scope.
If the dominant cause is timeout policy keyed to the wrong clock reference (internal ideal vs real SCL edges) → in-scope.
If the fix requires changing pull-ups/terminations/CMCs/cables/layout to make the waveform behave → out-of-scope (redirect to sibling pages).
Pass criteria (placeholder): no scope leakage; every troubleshooting path lands on a single owning page (X).
Diagram: Scope map (this page at the center; sibling pages around it)
Practical usage: when an investigation drifts into waveform compliance, stop and follow the sibling topic that owns those keywords. This keeps pages non-overlapping and SEO-clean.
Addressing mental model: 7-bit vs 10-bit vs “8-bit address” traps
Intent
Fix the most common addressing misunderstandings that cause false “multi-master” blame: clarify what a device address is, what it is not, and how ACK/NACK placement determines where a failure lives.
Terminology: three “address” representations (do not mix them)
7-bit device address: the identity of the target device on the bus (commonly written as 0x00–0x7F).
“8-bit address byte” (datasheet shorthand): (7-bit << 1) | R/W. It is one byte on the wire, not the address stored in most drivers.
10-bit device address: a wider identity encoded as a two-byte address sequence (details in later sections).
Example mapping (common datasheet trap): if the 7-bit address is 0x50, the on-wire address bytes are 0xA0 (write) and 0xA1 (read). Many drivers still expect 0x50 as the configured address.
Device address vs register address (different layers)
- Device address answers: “Which device is being targeted?” (decided in the address phase).
- Register/page/word address answers: “Which location inside that device?” (carried in the data phase).
- Mixing these layers produces failures that look random under multi-master load, because transactions collide on the bus while software misinterprets the failure location.
Trap 1: “0xA0 in the datasheet” entered as the device address
Likely cause: a datasheet lists the on-wire 8-bit address byte, not the 7-bit address field.
Quick check: shift right by 1 and compare (0xA0 >> 1 = 0x50).
Fix: store the configured device address in 7-bit form; let the controller append R/W on the wire.
Trap 2: register/page address treated as the device address
Likely cause: the “sub-address” is sent in the data phase, but software targets it in the address phase.
Quick check: capture a transaction; confirm that register/page bytes appear after the address ACK.
Fix: enforce a frame template: START → (device addr) → ACK → (reg/page) → ACK → data…
Trap 3: every NACK assumed to be “pull-up/waveform” (wrong page owner)
Likely cause: NACK is an information signal. The important question is where it occurs.
Quick check: classify NACK by phase: address-ACK (identity/capability/ownership) vs data-ACK (busy/write-cycle/policy).
Fix: instrument logs and analyzer triggers around the first ACK bit; only then decide whether to leave this page to a waveform page.
Diagram: Address byte framing and ACK placement (where failures live)
Debugging rule-of-thumb: first classify the NACK location. Address-ACK failures belong to identity/capability/ownership (this page); waveform compliance belongs to pull-up/edge/cable pages.
Boundary reminder: this section defines naming and byte framing only; rise-time and pull-up sizing belong to the pull-up network topic.
7-bit addressing: reserved ranges, general call, and “fake conflicts”
Intent
Prevent address-planning traps that masquerade as multi-master problems. The fastest win is separating true concurrency issues from address-layer “fake conflicts” such as reserved semantics, general call side effects, and duplicated default addresses after module swaps.
Engineering-only key points (no long spec tables)
- The 7-bit space contains reserved/special meanings. A safe address plan requires checking the I²C specification plus every device and bridge datasheet, rather than relying on a single “all addresses are free” assumption.
- General call / broadcast-like behavior can produce “multiple devices ACK the same address” symptoms that look like arbitration or bus contention but are actually address governance issues.
- The most common field failure is module replacement causing duplicated addresses: same part number, different strap defaults or configuration state → two responders on one address.
Common “fake conflict” patterns (symptom → first probe)
- Same address ACKs, but returned ID varies → first probe: read a fixed identity register (ID_REG placeholder) N times (X) and compare.
- Bus “gets weird” after an initialization sequence → first probe: capture the init transaction and look for a broadcast-like address phase (multiple ACK indications).
- Issue appears only after swapping a module → first probe: compare strap/default configuration and run an isolated scan per segment or per module.
- Certain address bands behave differently across vendors → first probe: verify whether the address falls into a reserved/special semantic range in the spec + datasheets.
Rule: if two responders ACK the same 7-bit address, treat it as an address governance failure until proven otherwise.
Address planning checklist (prevent + detect)
Prevent (governance)
- Maintain a single source of truth for address ownership (strap/OTP/EEPROM/software config).
- Avoid reserved/special semantic ranges unless explicitly required and documented.
- Define a module-swap rule: any replacement must pass an address uniqueness audit before field use.
Detect (conflict scan steps — placeholders)
- Run a single-master scan and record the ACK set (repeat X times).
- For every ACK address, run an identity probe (read ID_REG placeholder).
- Flag an address if identity varies across repeats or across segments/modules.
- Isolate the offender by segmenting (switch/offline module) and re-scan.
- Promote the scan + probe into production and field acceptance (timeout X ms).
Pass criteria (placeholder): address ACK set is stable across repeats (X), and every responding address maps to a single identity.
Diagram: 7-bit address map heatbar (avoid reserved semantics; audit collisions)
This heatbar is intentionally band-based (not a full reserved table): the safe workflow is “check spec + device + bridge constraints” and enforce a collision scan in production.
10-bit addressing: two-byte sequence, compatibility, and host capability traps
Intent
Explain why 10-bit devices often “work on paper but fail in practice”: the bus sequence is straightforward, but the system fails when host controllers, driver stacks, and in-between bridges do not implement the same 10-bit behavior end-to-end.
Two-byte addressing sequence (engineering view)
- 10-bit addressing places identity across two address bytes. A failure can stop at ACK#1 (first address byte) or ACK#2 (second address byte).
- Read paths can diverge from write paths in how the controller/stack forms the full transaction. When “write works but read fails”, treat it as a host stack sequence mismatch until proven otherwise.
- In multi-master systems, inconsistent 10-bit support across masters appears as “one master never gets ACK” even though the device is present and responds to the other master.
Capability sanity checklist (host + stack + bridge)
- Host controller explicitly supports 10-bit mode and exposes a configuration bit/API.
- Driver stack actually enables 10-bit (not only accepting a 10-bit value in software).
- Analyzer trigger can capture ACK#1 and ACK#2 positions for stop-point diagnosis.
- Arbitration-lost reporting exists (multi-master coexistence) and does not collapse into a generic NACK.
- Read transaction sequence is implemented consistently (no silent fallback to 7-bit assumptions).
- Bridge/switch/mux is transparent for 10-bit traffic or explicitly documents limitations.
- Device claiming 10-bit support is verified by stop-point behavior (ACK at both bytes, not only at a 7-bit compatible alias).
- Multi-master masters follow the same 10-bit probing policy (avoid one master changing bus state during discovery).
Pass criteria (placeholder): both masters complete write + read with stable stop points (X repeats), and no bridge introduces silent 10-bit truncation.
Transaction step table (stop-point oriented, minimal)
| Step | Bus action | Expected | Failure symptom |
|---|---|---|---|
| 1 | START | Bus transitions to address phase | Bus busy / stall before address byte |
| 2 | AddrByte1 | ACK#1 from target | NACK at ACK#1 → host mode/bridge limitation suspected |
| 3 | AddrByte2 | ACK#2 from target | NACK at ACK#2 → device capability/address mismatch suspected |
| 4 | Data… | Data ACKs stable | Write OK but read fails → stack read-sequence mismatch suspected |
Diagnosis method: locate the first missing ACK (ACK#1 vs ACK#2) and compare the failing master’s bus sequence against a known-good master.
Diagram: 10-bit transaction ladder (stop points annotated)
Multi-master hint: when one master succeeds and another fails, compare sequences step-by-step and classify the first missing ACK.
Address allocation & collision policy: rules that keep addresses unique
Intent
Treat I²C address uniqueness as a governance problem, not a debugging tactic. Define a single source of truth (SSOT), a deterministic allocation rule, and a collision policy that remains consistent across multiple masters.
Three allocation strategies (practical view)
- Static (hard-bound): simplest, but highest risk under module swaps and mixed inventory. Requires a controlled BOM + address registry.
- Strap-based: hardware-configurable address bits. Scales for modular designs, but needs assembly/acceptance checks (strap defaults and sampling timing can drift into collisions).
- Runtime provisioning (EEPROM / command): best for large node counts, but requires a clear “unprovisioned → provisioned” state machine and rollback rules on power-loss.
Single source of truth (SSOT) — multi-master requirement
- Only one authoritative registry defines “address → device identity” (manufacturing DB, device EEPROM, or a versioned host registry).
- All masters must consult the same SSOT; do not let each master infer truth from scans alone.
- After arbitration loss, a master must re-enter a consistent observation state (avoid “half recovery” that diverges registry state).
Collision detection (boot scan + runtime fingerprint)
Boot-time scan (identity-aware)
- Collect ACK set, repeat X times for stability.
- For each responding address, read ID_REG (placeholder) and build “Address → Identity”.
- Compare against SSOT expected list; mismatch triggers collision policy (no writes).
Runtime fingerprint (“abnormal ACK portrait”)
- Same address returns different identity across reads (strong collision indicator).
- ACK presence drifts over time (address appears/disappears).
- Mutually exclusive register values appear “interleaved” (two devices answering).
- One master sees stable access while another sees persistent NACK (collision or capability mismatch; collision must be excluded first).
Safe default policy: when collision is suspected, freeze writes and collect evidence (address, time, two identities) before recovery.
Collision response policy (containment first)
- Freeze writes to the suspect address range to avoid corrupting the wrong device.
- Switch to read-only identity probes (ID_REG placeholder) and confirm the collision evidence.
- Isolate by segment/module (switch-off branch, remove module) and re-scan to locate the offending node.
- If runtime reassignment is allowed, require a versioned SSOT update (epoch) and a full re-verify.
Pass criteria (placeholder): stable “Address → Identity” map across repeats (X) and across masters; no writes occur during suspect states.
Strategy comparison (choose based on scale and maintainability)
| Strategy | Pros | Risks | Best-fit |
|---|---|---|---|
| Static (hard-bound) | Predictable; minimal provisioning logic | Collides under module swaps; mixed inventory risk; poor scalability | Fixed single-board designs with stable BOM |
| Strap-based | Modular scaling; no write tool needed; quick field configurability | Strap defaults/sampling timing; assembly errors; needs acceptance checks | Boards/modules with reserved address ranges per slot |
| Runtime provisioning | Best scalability; flexible address re-assignment; supports large node counts | Bootstrapping complexity; power-loss consistency; requires state machine + rollback | Multi-node systems with tooling and lifecycle management |
Selection rule of thumb: modular systems prefer strap or runtime provisioning; large node counts favor runtime provisioning with a versioned SSOT.
Diagram: Address governance (manufacturing → device config → scan → runtime consistency → policy)
The diagram highlights the governance chain and the SSOT link that keeps multiple masters consistent.
Multi-master architecture: motives, topologies, and the failure magnets
Intent
Clarify why multi-master is not “two MCUs wired together”. Safe operation requires an ownership model, mutual exclusion, and consistent recovery behavior across all masters.
Typical motives for multi-master
- Redundant control: failover master for availability and serviceability.
- Shared peripherals: multiple processors needing the same sensors/EEPROM/PMIC access.
- Maintenance ownership: a service master that can temporarily take control during field diagnostics.
The failure magnet: two masters polling on timers with no mutex
- High collision probability when both masters hit the same windows (periodic concurrency).
- Symptoms drift: arbitration loss, retries, and recovery sequences create “random-looking” failures.
- Minimum fix is a mutual exclusion mechanism (token/semaphore/time-slot + backoff).
Topology 1 — Peer-to-peer multi-master
- Best fit: truly equal masters, shared responsibilities.
- Risk: frequent arbitration and conflicting recovery behavior.
- Must-have: token/ownership, backoff policy, unified recovery rules after ALOST.
Topology 2 — Active-standby (failover)
- Best fit: redundancy with clear primary ownership.
- Risk: split-brain (both masters think they are active).
- Must-have: role state machine, takeover criteria, write-protection during role transition.
Topology 3 — Segmented domains (each master owns a segment)
- Best fit: scale and fault containment with clear boundaries.
- Risk: bridge/switch policy mismatch and ambiguous cross-domain access.
- Must-have: boundary ownership rules, cross-domain access policy, fault-domain isolation.
Pass criteria (placeholders)
- Arbitration-loss rate under stress ≤ X per minute (or per transaction set).
- Failover (active-standby) takeover time ≤ X ms, with no double-writes during transition.
- After injected faults (reset/power cycle), masters converge to a consistent ownership state within X ms.
Diagram: Topology gallery (peer-to-peer / active-standby / segmented)
A topology decision should be paired with an explicit ownership/mutex strategy; otherwise timer-driven polling becomes the dominant failure source.
Arbitration deep dive: what happens on SDA and why the loser must stop driving
Intent
Arbitration is a physical, bit-level event on SDA: open-drain “0 wins over 1”. Once arbitration is lost, the master must stop driving immediately and switch to observe mode to avoid corrupting the winning transaction or stalling the bus.
The core rule (hardware reality)
- SDA is open-drain: devices can pull low (0) or release (1).
- If any device pulls low, the line is low: therefore “0 wins over 1”.
- Arbitration check: compare “intended bit” vs “observed SDA” at the sample point.
When arbitration is declared lost
Bit decision
- Intend 1 (release SDA), but read 0 → another master pulled low → ALOST.
- Intend 0 (pull SDA low), read 0 → consistent → continue.
Phase matters (address vs data)
- Lost in address phase: the winner is establishing the target; the loser must exit immediately to avoid interfering.
- Lost in data phase: risk is higher; continuing to drive can corrupt payload and prolong bus-busy time.
Common pitfall: bit-bang sampling errors (false arbitration loss)
- Sending “1” must be release, not “drive high”; if GPIO stays output, readback is not the real bus.
- Sampling too early/late around SCL high can read a transient and misclassify the decision point.
- Minimum self-check: when intending “1”, force SDA into input/open-drain release and confirm the line can be pulled low by another device.
Diagram: bit-level arbitration example (0 wins over 1)
The example shows the key condition: attempting “1” (release) but observing “0” (pulled low) triggers arbitration loss.
Arbitration-loss handling: a firmware state machine that does not stall the bus
Intent
After arbitration loss, the master must retreat deterministically: release SDA, stop generating clocks, and switch into observe/backoff before retrying. The goal is to prevent “phase-locked collisions” caused by synchronized retries.
The three actions immediately after ALOST
- Release SDA (ensure open-drain is not actively pulling).
- Stop driving (disable TX state, stop generating SCL).
- Switch to observe (listen for STOP/bus-free window before retry).
Retry policy: break synchronization
- Random backoff: choose delay in window [X..Y] to avoid periodic collisions.
- Priority backoff: higher-priority master retries earlier; lower-priority waits longer.
- Rule: do not retry immediately after observing bus-free; add jitter or priority separation.
Observe mode: exit conditions (placeholders)
- Exit observe when STOP detected and bus is free for ≥ X.
- If bus stays busy longer than X ms, classify as “bus-busy anomaly” and escalate to recovery policy.
Minimum logging fields for arbitration-loss forensics
- lost_arbitration_count
- phase (address / data)
- last_txn_id
- bus_busy_duration
- backoff_chosen (random/priority + value)
- observe_exit_reason (STOP / free-window / timeout)
Typical anomaly: still generating SCL after ALOST (bus stall trigger)
- Cause: driver not disabled, ISR/state-machine race, or wrong peripheral mode transition.
- Fast check: after ALOST, confirm SCL pulses stop within ≤ X (logic analyzer trigger on ALOST event).
- Containment: force-disable output enable and fall back to observe mode before retry.
Minimal implementation skeleton (states + events)
States
IDLE → REQUEST → WAIT_BUS_FREE → TX → (ALOST) → OBSERVE → BACKOFF → RETRY → TX
Events
REQ_IN / BUS_FREE / BYTE_SENT / ALOST_IRQ / STOP_SEEN / TIMEOUT
Diagram: arbitration-loss firmware state machine
The key property is deterministic retreat: stop driving immediately on ALOST, observe bus state, then retry with backoff to break synchronization.