Buffers / Isolators / Switches for I²C (and I³C Hooks)
← Back to: I²C / SPI / UART — Serial Peripheral Buses
Buffers, switches/muxes, and isolators make I²C scalable by segmenting capacitance, selecting branches to avoid conflicts, and breaking ground paths. The key is to pick the right category for the symptom and verify success with measurable metrics (NACK/hr, stuck/hr, recovery time) instead of “looks OK on the scope.”
H2-1 · Definition & Why you need them (Problem framing)
“Buffers / Isolators / Switches” are board-level tools that change the bus boundary. They do not “fix I²C” in general; they fix specific failure classes: capacitance overload, edge/threshold issues, address conflicts, and ground-domain / surge problems.
Three categories (engineering definitions)
Buffer / Repeater (segmenter)
- What it changes: splits the bus into segments to isolate capacitance and restore edges.
- What to watch: direction-detect latency, VOL/VIH translation, multi-master / clock stretching pass-through.
Isolator (galvanic barrier)
- What it changes: breaks the DC ground path; limits surge/ground shift coupling.
- What to watch: propagation delay/skew, failsafe idle states, power sequencing on both sides, CMTI.
Switch / Mux (channel selector)
- What it changes: connects only one branch (or a chosen set) at a time.
- What to watch: on-resistance/leakage, settling time after channel change, hot-plug transients.
Scope guard: this page focuses on bus segmentation, capacitance isolation, address conflict bypass, and isolation constraints. Detailed pull-up math, I³C HDR protocol behavior, and long-cable differential extenders belong to their owner pages.
Map symptoms to the right tool (4 pain points)
Capacitance overload (C budget)
Symptom: slow edges, intermittent NACKs, “works on bench / fails in system”.
Root cause: total bus capacitance exceeds rise-time budget (multiple devices, long traces, stubs).
Goal: split into segments so each segment meets edge timing without over-powering pull-ups.
Edge / threshold integrity
Symptom: “double edges”, spurious START/STOP, arbitration oddities, random bus-stall.
Root cause: edge accelerators, thresholds, or direction control create timing/logic ambiguity.
Goal: restore a clean open-drain “wired-AND” behavior while preserving stretching/arbitration needs.
Address conflicts / fanout
Symptom: two devices share an address; discovery/register reads collide.
Root cause: logical namespace conflict; electrical improvements cannot fix a protocol-level collision.
Goal: time/route separation: connect one branch at a time (Switch/Mux) to reuse addresses safely.
Isolation / ground shift / surge
Symptom: works until ESD/surge events, long harness, or mixed grounds; lockups become “seasonal”.
Root cause: common-mode noise/ground potential differences disturb thresholds and recovery.
Goal: galvanic barrier + explicit defaults so “idle/high/low” is deterministic during power and faults.
Keywords: I²C buffer, I²C isolator, I²C switch/mux, bus segmentation, capacitance isolation, address conflict bypass, hot-swap, multi-master, clock stretching.
Figure 1 · Scope comparison: single bus → segmented / isolated / multi-route
* Level translation is device-dependent. Always confirm VIH/VIL, VOL behavior, and idle defaults across rails.
H2-2 · Taxonomy: Buffer vs Repeater vs Rise-time Accelerator vs Hot-swap
Datasheet naming is inconsistent. Correct selection requires reading each part as a set of inserted functions on SDA/SCL: edge acceleration, direction control, current limiting, disconnect/containment, and timeouts. The first gating questions are usually: multi-master allowed? and clock stretching pass-through required?
Naming map (use behavior, not marketing terms)
Rise-time accelerator
What it does: injects pull-up current to speed rising edges under heavy C load.
What it doesn’t: cannot resolve address conflicts; may not preserve “wired-AND” behavior in corner cases.
Typical use: moderate capacitance overload when segmentation is not possible.
Gotcha: can create double edges/glitches if thresholds or stubs are marginal.
Buffer / Repeater
What it does: splits the bus into segments so each segment meets edge/timing budgets.
What it doesn’t: does not fix protocol-level conflicts; can change arbitration/stetching behavior if not transparent.
Typical use: capacitance isolation, fanout scaling, fault containment by segmentation.
Gotcha: direction-detect and delay can break multi-master arbitration if not specified.
Hot-swap / bus buffer with containment
What it does: limits hot-insertion transients; can disconnect a stuck-low segment; may add timeout logic.
What it doesn’t: not a general signal conditioner; containment behavior must match recovery firmware.
Typical use: modular boards, field-replaceable sensors, harsh ESD environments.
Gotcha: default disconnect/idle states can look like “missing devices” unless the sequence is designed.
Switch / Mux
What it does: routes one branch at a time to bypass address conflicts and isolate bad branches.
What it doesn’t: does not increase bus speed by itself; on-resistance and leakage still matter.
Typical use: same-address sensors, large fanout trees, debug isolation per branch.
Gotcha: channel switching requires settling time; otherwise burst NACKs occur.
Two compatibility gates (decide early)
- Multi-master / arbitration: any added latency or non-transparent thresholding can cause false arbitration loss or missed contention.
- Clock stretching pass-through: accelerators/timeouts/disconnect logic can shorten the “legal wait” window and force unexpected timeouts.
Figure 2 · Where functions “insert” on SDA/SCL (read parts by behavior)
Reading tip: if a feature block exists internally (edge accel / timeout / disconnect), confirm its default behavior during power sequencing and fault events.
H2-3 · When to use which: Decision tree (1 page filter)
This decision tree is the page’s operational core: start from symptoms and non-negotiable constraints, then land on one category with the minimum set of must-check specs (threshold X placeholders).
How to use the filter
- Input: symptom + constraints (multi-master? stretching? hot-plug? isolation?).
- Output: category A/B/C/D + recommended device class + 3–6 must-check specs (X placeholders).
- Rule: address conflicts are logical—electrical cleanup cannot resolve them; isolate them with routing (Mux/Switch).
Figure 3 · Yes/No decision tree (category + must-check specs)
Leaf outputs intentionally stay short. Detailed spec interpretation and verification steps are handled in later owner sections (Key specs, Layout, Engineering checklist).
Outcome landing points (quick reference)
A · Capacitance segmentation
Primary tool: Buffer/Repeater. Confirm stretch pass-through (X), latency (X), VOL/VIH domain (X).
B · Address conflict / fanout
Primary tool: Switch/Mux. Confirm Ron (X), leakage (X), channel settle time (X).
C · Galvanic isolation / ground shift
Primary tool: Isolator. Confirm CMTI (X), default idle states (X), delay/skew (X).
D · Hot-plug / stuck-bus containment
Primary tool: Hot-swap buffer. Confirm disconnect rules (X), timeout window (X), power-off behavior (X).
Keywords: I²C decision tree, I²C buffer vs mux, I²C isolator selection, hot-swap I²C, clock stretching pass-through, multi-master compatibility.
H2-4 · Electrical segmentation model (what changes after you insert a buffer)
A buffer turns one shared RC into multiple RC segments, but it also introduces behavioral elements (direction control, thresholding, and optional containment). Success requires verifying both the electrical budget and the logic compatibility.
Three-layer view (why it helps, why it can break)
Layer 1 · RC segments
Each segment has its own Cseg and pull-up budget. The goal is to keep each segment within rise-time and VOL margins without excessive pull-up power.
Layer 2 · Inserted behavior
Direction detect latency, threshold/level translation, and optional edge assist can change the meaning of “low wins” and “idle is high” at boundaries.
Layer 3 · System compatibility
Multi-master arbitration, clock stretching pass-through, and bus-clear/recovery behaviors must remain deterministic across all segments.
New failure modes after segmentation (keep them deterministic)
Direction latency
Trigger: contention / fast transitions near thresholds.
Symptom: false arbitration loss or missed contention.
Root: boundary delays distort “low dominates” timing.
Threshold mismatch
Trigger: mixed voltage domains or weak pull-ups.
Symptom: burst NACKs / “device disappears”.
Root: VIH/VIL or VOL translation not aligned across segments.
Over-aggressive edge assist
Trigger: long stubs / marginal layout.
Symptom: double edges, spurious START/STOP.
Root: current injection plus reflections creates false transitions.
Stretch/timeout mismatch
Trigger: slow slave response / long operations.
Symptom: master timeouts only behind the buffer.
Root: internal timeout policy shortens effective stretch window.
Containment defaults
Trigger: power sequencing / hot insertion.
Symptom: channel appears missing or permanently busy.
Root: disconnect/idle defaults not aligned with firmware discovery.
Figure 4 · Equivalent segmentation model (Cseg + pull-up budget + inserted behavior)
Spec placeholders (X) are intentionally left open: set them using system requirements (bus speed, timeout policy, device count, and fault model).
Keywords: I²C bus segmentation model, buffer direction detect latency, threshold shift, rise-time budget, clock stretching compatibility, multi-master arbitration.
H2-5 · Switch/Mux for address conflicts & fanout (what it really solves)
An I²C switch/mux solves topology exposure: at any moment, only one downstream branch is connected to the upstream bus. This enables address reuse, controlled fanout, and fault isolation. It is not a universal signal-quality upgrade.
What a Mux really changes (and what it does not)
- Changes: the bus only “sees” the selected branch (load + faults) at a time.
- Does not guarantee: faster edges; Ron and channel capacitance can slow transitions.
- Design rule: switching requires settle time; channel changes must be treated like topology events.
Three scenarios a Switch/Mux actually solves
Address conflict (same-address devices)
Goal: allow two devices with the same address to coexist and be accessed deterministically.
How Mux does it: only one branch is connected at a time, so the address namespace never collides.
Pitfall: switching channels and immediately issuing commands can cause burst NACKs if the line has not settled.
Pass (X): after switching, bus returns to idle-high within X and no spurious START/STOP is observed.
Fanout (many branches / slots)
Goal: scale device count without exposing the upstream bus to all branch capacitance at once.
How Mux does it: upstream sees only the selected branch load (C + leakage) rather than total fanout sum.
Pitfall: Ron and channel capacitance can push rise-time beyond budget on weak pull-ups.
Pass (X): the selected branch meets rise-time / VOL budgets with margin ≥ X.
Fault containment (debug isolate / bad branch)
Goal: prevent one stuck-low or leaky branch from taking down the whole bus.
How Mux does it: disconnect the suspected branch and validate bus health per-channel.
Pitfall: switching can inject transients; without a clean recovery sequence, failures look non-repeatable.
Pass (X): isolating a bad channel restores a stable bus with error rate ≤ X.
Mux/Switch must-check spec list (minimum set)
- Ron / Rseries: limits VOL margin and slows edges; treat as part of the rise-time budget (X).
- Cchannel + Coff: controls how much load is exposed when selected, and how well unselected branches are isolated.
- Leakage: can prevent a clean idle-high or cause “slow drift” that becomes NACK bursts.
- Power-off behavior: confirm unpowered branches do not back-power upstream or clamp lines unintentionally.
- Switch settle time (X): define a firmware wait window before the first transaction after switching.
Figure 5 · Switch/Mux channel selection (upstream sees one branch at a time)
Implementation tip: treat channel selection as a state transition. Always define a switch-settle window (X) before the first transaction.
Keywords: I²C mux address conflict, I²C switch fanout, branch isolation, Ron leakage settle time, debug isolate I²C.
H2-6 · Isolation: galvanic barrier + timing/logic constraints
Isolation does not exist to “clean the signal”. It exists to break DC ground paths and contain surge/common-mode coupling across domains. The trade-off is system constraints: delay/skew, edge rebuilding, and deterministic default states during power and faults.
Isolation success is defined by determinism: idle-high is correct, low dominates correctly, stretching is either supported or explicitly disallowed, and power sequencing does not create ghost powering or stuck-bus conditions.
Seven must-check points (actionable, X placeholders)
1) Prop delay / skew (X)
Confirm the added delay does not collapse setup/hold margins for START/STOP and sampling windows across the barrier.
2) Clock stretching
Verify whether low-level hold is transparently passed through, especially under slow-device operations and master timeout policies.
3) Failsafe high/low
Confirm deterministic defaults when either side is unpowered or floating: idle-high correctness must remain valid by design.
4) Power sequencing (A/B)
Validate both power-up orders. Prevent ghost powering, unintended clamping, or stuck-low due to partial power states.
5) ESD/Surge path
Ensure surge/ESD energy does not bypass the barrier through PCB return paths, TVS placement, shields, or cable grounds.
6) CMTI (X kV/µs)
Match common-mode transient immunity to the worst-case environment; confirm no false toggles or latch conditions under fast dv/dt.
7) Bus idle correctness
Confirm idle-high is stable and unambiguous across both pull-up networks and default states; prevent slow drift and spurious START/STOP.
Figure 6 · Dual-domain isolation model (default idle + constraints)
The barrier’s job is containment. The system’s job is to keep timing, defaults, and recovery deterministic across both power domains.
Keywords: I²C isolation, galvanic barrier, CMTI requirement, failsafe idle state, power sequencing, delay skew budget, surge common-mode containment.
H2-7 · “Transparent or not”: clock stretching, multi-master, arbitration
“Transparent” is not “signals pass”. It means protocol semantics remain intact across the inserted device: low-dominant arbitration, multi-master coexistence, clock stretching, and Repeated START. Many buffers/switches/isolators add direction detection, thresholds, or timeouts that can silently break these behaviors.
Must-ask questions (before selecting a part)
- Is multi-master explicitly supported, or assumed single-master?
- Is arbitration guaranteed correct with internal direction control and propagation delay?
- Is clock stretching passed through without an internal timeout/disconnect policy?
- Does Repeated START remain intact (no spurious STOP/START) under edge rebuilding?
- Does the device allow bus clear sequences to propagate and recover stuck states?
Compatibility matrix (cards, actionable)
Multi-master pass-through
What to confirm: no hidden master/slave role is introduced by direction logic.
Why it breaks: conditional pass-through can distort simultaneous drive visibility.
Quick check: emulate two masters contesting a bit window and observe deterministic loss behavior.
Pass (X): the losing master detects SDA low within X and releases without bus lock.
Arbitration correctness
What to confirm: low-dominant state is visible fast enough to preserve arbitration semantics.
Why it breaks: direction detect latency / threshold rebuild can delay “low wins”.
Quick check: force one master to release while another pulls low; measure observed timing at both sides.
Pass (X): arbitration decisions match the direct-bus reference within X budget.
Stretching passthrough / timeout
What to confirm: SCL low-hold is passed through as-is, or the limitation is explicit.
Why it breaks: internal timeout/disconnect policies treat long stretching as stuck-bus.
Quick check: trigger slow-device operations; confirm no cut-off at the device boundary.
Pass (X): stretching holds for ≥ X and the master never sees spurious recovery events.
Repeated START integrity
What to confirm: combined transactions remain valid across the inserted device.
Why it breaks: edge rebuilding or thresholding can mis-detect short gaps as STOP/START.
Quick check: loop write + repeated-start + read; watch for NACK bursts and false bus events.
Pass (X): ≥ X cycles with zero spurious STOP/START and error rate ≤ X.
Bus clear support
What to confirm: recovery sequences can propagate and restore idle-high deterministically.
Why it breaks: disconnect/hold states can trap recovery attempts on one side.
Quick check: create a stuck-low, then execute bus-clear (SCL toggles/reset) across the boundary.
Pass (X): bus returns to idle-high within X and remains stable for ≥ X time.
Figure 7 · Arbitration “low wins” (latency can cause mis-detect)
Interpretation: arbitration requires fast visibility of low. Direction logic, threshold rebuild, or propagation delay can shift “what is seen when” and break semantics.
Keywords: I²C arbitration, multi-master compatibility, clock stretching passthrough, repeated start integrity, bus clear recovery, direction detect latency.
H2-8 · Key specs that actually matter (selection checklist)
Datasheets contain many parameters, but only a small subset determines real-world success. This checklist keeps the minimum set that maps directly to failure modes: bus stuck, false START, NACK bursts, and arbitration loss.
Selection checklist (grouped by device class)
Buffer / Repeater (must-check)
- VIH/VIL compatibility (X): mismatch → false highs/lows, NACK bursts.
- VOL pass-through / sink behavior: weak low drive → “busy” bus or marginal VOL.
- Direction detect latency (X): late visibility → arbitration/repeated-start failures.
- Edge assist current (if any): too aggressive → false START/STOP on reflections.
- Added Cin/Cout: rise-time budget collapse on weak pull-ups.
- Internal timeout policy: can cut legal stretching and trigger recovery loops.
- Power-off I/O state: clamp/ghost power → stuck bus, non-deterministic boot.
Use this set when the goal is capacitance segmentation or edge restoration.
Switch / Mux (must-check)
- Ron / ΔRon (X): impacts VOL margin and edge rate in the selected branch.
- Cchannel / added C: defines exposed load per channel and rise-time margin.
- Off isolation (Coff): determines how well bad branches are truly isolated.
- Leakage (on/off): idle drift → intermittent NACK bursts and slow “bus busy”.
- Switch settle time (X): must be respected before first transaction.
- Power-off behavior: avoid back-powering or unintended clamping.
- Hot insertion transient behavior: limit glitches that resemble START/STOP.
Use this set when the goal is address reuse, fanout control, or fault containment.
Isolator (must-check)
- Propagation delay / skew (X): collapses setup/hold → arbitration/restart issues.
- CMTI (X kV/µs): low CMTI → false toggles under fast dv/dt environments.
- Failsafe defaults: power-off high/low/hold must keep idle deterministic.
- Stretching compatibility: confirm pass-through vs internal timeout constraints.
- Power sequencing rules: prevent ghost powering and one-sided clamping.
- Edge rebuild model: threshold/drive rules can create false START/STOP if mismatched.
- Surge/ESD path awareness: ensure energy does not bypass the barrier via layout returns.
Use this set when the goal is ground shift, surge/common-mode containment, or safety isolation.
Figure 8 · Spec → Failure mapping (what each parameter can break)
Use the mapping to prioritize specs that correlate with the observed failure. The “X” thresholds must be set by system timing, pull-up power, and recovery policy.
Keywords: I²C selection checklist, buffer specs that matter, mux Ron leakage, isolator CMTI delay skew, failure mapping bus stuck false start NACK arbitration.
H2-9 · Hardware design patterns (topologies that scale)
These patterns are repeatable topology templates for scaling I²C buses using Switch/Mux, Buffer/Repeater, and Isolator. Each pattern focuses on “why it works”, the most common pitfalls, and a minimal verification checklist (with pass thresholds as X placeholders).
Pattern cards (copy-paste topology logic)
Pattern A · Mux fanout (branching & fault isolation)
Use case: many sensors/slots/branches; only one branch is connected at a time to limit exposed load and isolate bad branches.
Wiring: MCU trunk → Switch/Mux → CH0…CHn (each channel is a short local stub + local devices).
- Pitfall: channel switching is a topology event → requires settle window (X).
- Pitfall: Ron/Cchannel slow edges; a mux is not a signal-strength tool.
- Pitfall: off-leakage/Coff can allow “ghost” coupling to unselected branches.
- Verify: after switching, bus returns to idle-high within X.
- Verify: repeated transactions per-channel ≥ X cycles with error rate ≤ X.
- Verify: a stuck-low branch can be isolated without destabilizing the trunk (containment time ≤ X).
Pattern B · Buffer segmentation (trunk stays light)
Use case: heavy downstream capacitance or long routing; keep the trunk stable by splitting the bus into segments.
Wiring: MCU short trunk → Buffer/Repeater boundary → downstream segment (many devices or longer routing).
- Pitfall: “transparent” is not guaranteed; multi-master/arbitration/stretching may be altered.
- Pitfall: direction detect latency can cause repeated-start/arbitration failures under corner timing.
- Pitfall: internal timeouts can treat legal stretching as stuck-bus and force disconnect.
- Verify: START/STOP and idle behavior match the direct-bus reference within X.
- Verify: slow-device stretching is preserved for ≥ X without forced recovery.
- Verify: bus-clear sequences work on both sides and recover within X.
Pattern C · Isolated segment (ground shift & common-mode containment)
Use case: cross-chassis, long cable, or separate grounds where DC ground coupling and surge/common-mode events must be contained.
Wiring: Domain A (GND_A) → Isolator barrier → Domain B (GND_B), with independent pull-ups and local decoupling per side.
- Pitfall: propagation delay/skew adds a timing constraint (not “cleaner signals”).
- Pitfall: failsafe defaults during power-off must keep a deterministic idle state.
- Pitfall: ESD/surge energy can bypass the barrier via return paths if placement is wrong.
- Verify: any A/B power sequence keeps bus non-stuck; recovery time ≤ X.
- Verify: dv/dt events produce no false toggles; CMTI margin ≥ X.
- Verify: idle-high is stable and correct on both sides for ≥ X.
Pattern D · Buffer + Mux (scalable + containment)
Use case: the trunk must be stable while multiple branches exist; faults must be isolated without taking down the entire bus.
Wiring: MCU trunk → Buffer boundary (stabilize) → Mux selector → CH0…CHn (per-branch isolation).
- Pitfall: two-layer state machines (buffer + mux) increase recovery sequencing requirements.
- Pitfall: buffer transparency limits + mux settle time stack up against timing budget.
- Pitfall: internal timeouts/disconnect features can mis-classify legal behavior.
- Verify: fault injection (one branch stuck-low) is contained by disconnecting the branch; recovery ≤ X.
- Verify: switch/recover sequence repeated ≥ X times with zero random failures.
- Verify: per-branch bring-up logs are deterministic (selection, retries, recovery count).
Figure 9 · Four scalable topology templates (one canvas, four quadrants)
Reading guide: pick the quadrant that matches the constraint (fanout, segmentation, isolation, containment). Then enforce the minimal verification points with system-defined X thresholds.
Keywords: scalable I²C topology patterns, mux fanout, buffer segmentation, isolated I²C segment, fault containment template, verification checklist.
H2-10 · Layout & EMI: what these parts change on a real PCB
Adding a buffer/mux/isolator changes the real board: it introduces a new return-path decision point, a new coupling location, and a new supply-noise injection site. The items below are the most common board-level traps that create intermittent I²C failures (NACK bursts, false START/STOP, bus busy, and stuck-low) even when “it worked on the bench”.
Eight layout pitfalls (Symptom → Root cause → Board fix → Pass)
1) Long stubs at the boundary
Symptom: false START/STOP, random bus events, sporadic retries.
Root cause: boundary node becomes a reflection/coupling point when a side stub is long.
Board fix: keep trunk-to-device short and straight; fan-out from the device; avoid unused branches.
Pass (X): glitch width/amplitude ≤ X and protocol no longer mis-triggers.
2) Decoupling too far
Symptom: failures during switching, hot events, or load changes.
Root cause: supply inductance injects noise into thresholds/direction logic at the boundary.
Board fix: place decaps at pins; keep the power-return loop tight; isolate-side decaps for isolators.
Pass (X): repeat switching/edge-stress ≥ X cycles with zero errors.
3) Broken return path / plane splits
Symptom: random NACK bursts that correlate with environmental noise or other subsystems.
Root cause: SCL/SDA reference plane discontinuity raises common-mode and coupling sensitivity.
Board fix: keep continuous reference under trunk and boundary; avoid routing across splits near the boundary.
Pass (X): in-noise conditions, error rate ≤ X and no stuck-bus events.
4) ESD/TVS placed too far from the port
Symptom: ESD passes once but the bus becomes “fragile” later; intermittent stuck-low.
Root cause: energy enters the boundary device before clamping; return path not short.
Board fix: protect at the entry; route clamp return to the nearest appropriate ground with minimal loop area.
Pass (X): after ESD stress, bus recovers within X and remains stable for ≥ X.
5) Channel-to-channel coupling (mux)
Symptom: unselected branches “move” or appear to respond; idle drift.
Root cause: long parallel routing + Coff/leakage creates ghost coupling into off channels.
Board fix: separate channels, shorten channel segments, add ground separation and avoid long parallelism.
Pass (X): off channels show no false edges above X during worst-case trunk activity.
6) Pull-ups placed in the wrong segment
Symptom: idle not deterministic; edges vary unpredictably across segments.
Root cause: after segmentation/isolation, a global pull-up assumption breaks the boundary behavior.
Board fix: treat each segment as a local domain; place pull-ups per segment and match rail intent.
Pass (X): idle-high stability ≥ X and no boot-time stuck events across power sequences.
7) Routing near high dv/dt nodes
Symptom: failures correlate with power stages, motor drive, or switching activity.
Root cause: injected common-mode/threshold noise at the boundary creates false edges and sampling errors.
Board fix: keep trunk and boundary away from high dv/dt; add ground shielding and shorten loops.
Pass (X): under worst-case switching, errors remain ≤ X and no false START/STOP.
8) “Bypassing” the isolation barrier
Symptom: isolation added but common-mode sensitivity persists or worsens.
Root cause: shield/TVS return ties domains at high frequency; energy sneaks around the barrier.
Board fix: define a clear shield/chassis strategy; clamp at the entry; keep barrier return paths separated.
Pass (X): dv/dt or surge events cause no false toggles; recovery within X.
Figure 10 · Layout focus: boundary device as a coupling/return/ESD center
Layout intent: treat the boundary device as a center for decoupling, return-path continuity, and port protection placement. Segment boundaries should be visible and testable.
Keywords: I²C layout pitfalls, mux channel coupling, boundary decoupling, return path continuity, ESD placement, isolation bypass avoidance, false start stop EMI.
Engineering checklist (design → bring-up → production)
This checklist converts segmentation (buffers), channel selection (switch/mux), and galvanic isolation into measurable acceptance criteria. Each item is written as an action with a record field and a pass threshold (X).
A) Design-time checks (before layout freeze)
- Confirm topology intent: segmentation vs. address-conflict avoidance vs. galvanic barrier; forbid “one part fixes everything.”
- Verify transparency requirements: clock stretching passthrough, repeated START integrity, and (if applicable) arbitration/multi-master behavior.
- Set timeout policy: define master timeout (X ms) and verify that any buffer/isolator internal timeout does not conflict.
- Budget added loading: account for per-channel capacitance and leakage; ensure idle-high remains stable across all segments (X margin).
- Define fail-safe states: power-off behavior (A-side off / B-side on) must keep SDA/SCL in valid idle state (X condition).
- Plan containment hooks: ensure a stuck-low branch can be disconnected or isolated without taking down the upstream bus.
- Define record fields: NACK burst rate, stuck-low duration, bus-clear attempts, per-channel failure map.
Idle-high stability across all branches: X (min margin) · Transparency checks pass under worst-case load (X) · No unintended back-powering.
B) Bring-up checks (first power-on → system validation)
- Verify bus-idle correctness: SDA/SCL idle-high observed on every segment/channel; log idle variance (X).
- Confirm clock stretching passthrough: test worst-case slave delay (X ms) across the inserted device; log timeout count.
- Validate repeated START: run combined transactions (addr → restart → read) through every segment; log transaction error rate (X).
- Check channel switching behavior: mux enable/disable transitions must not glitch upstream lines; log switch transient events (X).
- Confirm bus-clear recovery: 9 pulses + STOP sequence works across all segments; log recovery time (≤ X ms).
- Fault-inject stuck-low: force SDA low on one branch; verify containment (upstream remains alive); log disconnect/recovery counters.
- Power sequencing test: one side unpowered (isolation/buffer) must not corrupt the active side; log any false START/STOP events.
Bus-clear success rate ≥ X% · Recovery time ≤ X ms · NACK burst rate ≤ X/hour · No upstream lockups during branch faults.
C) Production checks (fixture-friendly & measurable)
- Run per-branch scan: enumerate each mux channel / segment; record detected device count and address map.
- Log error histogram: NACK bursts, arbitration loss (if used), stuck-low events/hour; enforce limits (X).
- Execute a short fault-injection: force a controlled “bus busy” window; confirm automatic recovery; record recovery time (X).
- Verify power-off behavior: remove branch power (simulate card removal); confirm no false edges upstream; record glitch count (X).
- Enforce configuration lock: mux control register and strap pins must match golden settings; record config signature.
- Store traceability fields: board ID, firmware build, branch map, failure counters, retest count (X).
Per-branch enumeration pass ≥ X% · Field counters within limits (X) · Retest rate ≤ X% · No “stuck-bus” escapes.
Applications & IC selection logic (before FAQ)
This section maps real board-level use cases to a category decision (Buffer / Switch(Mux) / Isolator), then lists the gating specs that decide success. Example material numbers are provided as starting points (package/suffix/availability must be verified).
Recommended: Buffer (segmentation) + optional Mux (containment).
Acceptance: containment recovery ≤ X ms; stuck/hr ≤ X.
Recommended: Switch/Mux (only one downstream visible at a time).
Acceptance: no upstream glitch during channel switch; off-leakage ≤ X.
Recommended: Isolator (galvanic barrier) with defined failsafe idle.
Acceptance: CMTI ≥ X kV/µs; skew ≤ X; idle state correct.
Recommended: Hot-swap buffer (disconnect + recovery) and clear logging hooks.
Acceptance: automatic disconnect on stuck-low; recovery success ≥ X%.
Selection gates (if/then, with X thresholds)
- If galvanic barrier is required → choose Isolator; then gate: CMTI ≥ X, propagation delay ≤ X, skew ≤ X, failsafe idle correct.
- If same-address conflict exists → choose Switch/Mux; then gate: off-leakage ≤ X, per-channel capacitance ≤ X, switching does not glitch upstream.
- If capacitance / fanout is the limiting factor → choose Buffer/Repeater; then gate: transparency for stretching/repeated START, direction-detect latency ≤ X, idle-high stability margin ≥ X.
- If hot-plug is expected → require disconnect/containment; then gate: stuck-low detect time (X), bus-clear behavior, recovery time ≤ X.
- If multi-master/arbitration must be preserved → restrict to parts explicitly supporting arbitration correctness; validate with fault injection and counters.
- TI TCA4307 — hot-swappable I²C buffer with stuck-bus recovery
- TI TCA4311A (or TCA4311) — hot-swap 2-wire bus buffer
- ADI LTC4300A-1 / -2 — hot-swappable 2-wire bus buffers
- ADI LTC4300A-3 — level-shifting hot-swappable 2-wire bus buffer
- TI TCA9517A — level-shifting I²C bus repeater
- NXP PCA9515A — I²C-bus repeater (bidirectional buffers)
- NXP PCA9517A — level-translating I²C-bus repeater
- ADI LTC4311 — rise-time accelerator (support part, not a segment isolator)
- TI TCA9548A — 8-channel I²C/SMBus switch with reset
- TI TCA9546A — 4-channel I²C/SMBus switch with reset
- NXP PCA9548A — 8-channel I²C-bus switch with reset
- NXP PCA9546A — 4-channel I²C-bus switch with reset
- NXP PCA9543A/43B — 2-channel I²C-bus switch (interrupt logic options)
- NXP PCA9646 — buffered 4-channel 2-wire bus switch
- TI ISO1540 — bidirectional I²C isolator (capacitive isolation)
- TI ISO1541 — isolated unidirectional clock + bidirectional data I²C isolator
- ADI ADuM1250 — hot-swappable, bidirectional isolated I²C interface
- ADI ADuM1251 — 1 bidirectional + 1 unidirectional channel variant
Recommended topics you might also need
Request a Quote
FAQs (buffers / isolators / switches) — quick triage with measurable pass criteria
This FAQ only covers failure modes introduced by inserting a buffer/repeater, switch/mux, or galvanic isolator. Every answer follows the same 4-line structure: Likely cause / Quick check / Fix / Pass criteria (thresholds as X).
