I²C Expander / Hub / Mux — Address Conflicts, Isolation, Deep Fan-Out
← Back to: I²C / SPI / UART — Serial Peripheral Buses
I²C expanders, hubs, and multiplexers make large I²C systems predictable: resolve fixed-address conflicts, isolate capacitance and fault domains, and scale fan-out with deterministic routing and recovery.
The core is not “adding parts,” but defining segments, pull-up domains, and firmware route/timeout rules so every branch can be measured, isolated, and re-initialized to a known-good state.
What it is: Expander vs Hub vs Mux
Expander, mux, and hub/switch are not interchangeable. Each changes the I²C system in a different way: one extends I/O, one selects branches, and one segments electrical domains.
Core behavior (the one-liner that prevents mis-buying)
- Expander: turns I²C register reads/writes into extra GPIO/IRQ/config bits (remote I/O bank). Not for: resolving identical I²C device addresses.
- Mux: connects exactly one downstream branch at a time (selectable branch connectivity). Not for: “boosting” signal integrity; it only changes what is connected.
- Hub / Switch / Buffer: splits a large bus into smaller electrical segments (cap/fault containment domains). Not for: fixing same-address conflicts by itself.
Who solves what (fast mapping)
Address conflicts
- Mux: Yes (risk: routing/state)
- Hub/Switch: No (does not change addresses)
- Expander: No (extends I/O, not address space)
Capacitance isolation
- Hub/Switch: Yes (risk: added delay)
- Mux: Often yes (risk: one-branch-only)
- Expander: No
Fan-out scaling
- Hub/Switch: Yes (risk: segment management)
- Mux: Yes (risk: latency)
- Expander: Partial (I/O fan-out only)
Fault containment
- Hub/Switch: Yes (risk: reset policy)
- Mux: Yes (risk: stuck-select state)
- Expander: Limited (I/O domain only)
Deep I²C fundamentals (protocol basics, pull-up math, multi-master details) should live on their owner pages, then be referenced from this page with links.
When you need it: Decision triggers & anti-patterns
The correct choice starts from a measurable symptom. Treat “mux/hub/expander” as an engineering decision, not a wiring shortcut.
Decision triggers (symptom → quickest check → recommended class)
Fixed address conflicts
- Symptom: multiple identical devices cannot coexist.
- Quick check: one device works; two collide.
- Use: Mux (or address translator where applicable).
Capacitance over budget
- Symptom: stable on short harness, fails when fully populated.
- Quick check: remove a branch and edges improve.
- Use: Hub/Switch segmentation (mux helps only when branches are mutually exclusive).
Hot-plug / fault containment
- Symptom: one bad module drags down the whole bus.
- Quick check: unplug a branch and recovery is immediate.
- Use: Switch with disable/reset (mux also helps for isolation and root-cause).
Deep fan-out / multi-board
- Symptom: a single trunk must serve many endpoints or modules.
- Quick check: 1-level works; cascaded tree adds timeout/latency.
- Use: Segmented architecture first, then local mux where needed.
GPIO shortage / simple control
- Symptom: not enough pins for enables, interrupts, chip-select-like lines.
- Quick check: I/O count is the bottleneck, not I²C address space.
- Use: Expander (treat as register-mapped I/O).
Anti-patterns (common mistakes that create hidden failure modes)
- Adding a mux “to simplify wiring” without a routing model: increases latency and introduces new stuck states (select register, brownout residue, non-deterministic defaults).
- Treating a mux as a signal-integrity fix: the electrical problem remains; the system only hides it by reducing what is connected at a time.
- Ignoring firmware complexity: concurrency bugs cause “wrong device accessed”, deadlocks, and recovery loops that never converge.
A safe design treats channel selection, bus transactions, and error recovery as an atomic sequence with explicit rollback.
Architecture patterns: tree, cascade, segmentation
Common I²C expansion systems converge to a few repeatable templates. The key is to choose a topology that matches the dominant constraint: address conflicts, electrical loading, or fault containment.
Template A · 1×Mux → 8 sensors (mutually exclusive branches)
- Benefit: resolves identical-address devices by putting them on separate channels.
- Cost: adds per-transaction overhead (select → transact → deselect).
- Biggest risk: wrong-channel access caused by missing locks or incomplete rollback on errors.
- Design hooks: explicit channel API, channel-state readback (if available), and per-channel health counters.
Template B · 2-level mux tree → 64 endpoints (scalable fan-out)
- Benefit: scales endpoint count without adding new I²C controllers.
- Cost: latency compounds (two selections per access), and timeouts must be re-budgeted.
- Biggest risk: recovery complexity—brownout or partial init can leave the tree in a non-deterministic route.
- Design hooks: path encoding (A:ch, B:ch), deterministic init sequence, and staged isolation for root-cause.
Template C · Hub segmentation + per-segment pull-ups + per-segment reset (maintainable systems)
- Benefit: isolates capacitance and faults by dividing the bus into electrical domains.
- Cost: more rails/pull-up domains to manage and verify; added propagation delay per segment boundary.
- Biggest risk: “ghost-powering” or stuck states when a segment browns out while the trunk stays alive.
- Design hooks: per-segment reset/enable, test points, and power-good gating for deterministic re-init.
Practical note: keep expanders physically close to the loads they control (enables, resets, interrupt aggregation). Treat them as “register-mapped I/O banks”, not address-conflict solvers.
Address conflict strategies (mechanism-based choices)
Identical-address devices are solved by mechanisms, not guesses. Choose the simplest deterministic option first, then add routing only when required.
Mechanism 1 · Hardware address straps (A0/A1/… pins)
- Pros: deterministic, concurrency-safe, minimal firmware overhead.
- Cons: limited address variants; BOM/assembly variants must be controlled.
- Production consistency hooks: strap BOM table, test points, and explicit “no-float” rules for strap pins.
Mechanism 2 · I²C mux (separate channels for same-address devices)
- Pros: scales to many identical devices; adds isolation and root-cause capability.
- Cons: adds latency and routing state; requires a channel-lock and rollback model.
- Determinism hooks: define default channel state, enforce re-init after brownout, and log active channel on faults.
Mechanism 3 · Address translator (concept + risks only)
- Idea: remaps a downstream device address to a different upstream address, making identical devices appear unique.
- Risk: compatibility boundaries; some transactions or timing assumptions may behave differently under translation.
- Usage rule: treat translation as a routed subsystem that needs explicit validation and recovery behavior.
Mechanism 4 · Power sequencing / isolation so only one device is online
- Pros: minimal extra silicon in some designs.
- Cons: fragile assumptions—faults, hot-plug, or brownouts can break the “never online together” guarantee.
- Safety hook: always pair with a forced recovery path (disable/reset) when sequencing invariants are violated.
Electrical budgeting with segmentation (cap, rise-time, pull-up domains)
Segmentation makes a “too-heavy” I²C bus controllable by separating the load into a trunk budget and branch budgets. Mux-based topologies help because the trunk sees only the active branch; hub/switch segmentation helps because it creates electrical domains.
1) Make capacitance controllable: Ctrunk + Cbranch(i)
- Ctrunk covers the trunk routing, connectors on the trunk, protection/loading that is always connected, and the upstream side of segmentation devices.
- Cbranch(i) covers each branch’s routing, devices, local protection, and any off-board harness on that branch.
- Mux effect: the trunk sees only the selected branch at a time (active branch only), reducing the effective parallel load.
- Hub/switch effect: the boundary prevents a large branch from directly dragging down the trunk edge, but adds boundary behavior that must be validated.
Note: detailed pull-up sizing formulas belong in the pull-up chapter; this section focuses on how segmentation changes the budgeting model.
2) Pull-up domains: trunk pull-ups vs per-branch pull-ups
- Trunk pull-ups keep the core bus deterministic (known idle-high, known recovery behavior) even if branches are disabled or unplugged.
- Per-branch pull-ups (common with hub segmentation) let each branch meet its own rise-time target and isolate slow/heavy branches.
- Cross-rail caution: pull-up rails must match the powered domain; otherwise a powered rail can back-feed an unpowered domain through I/O structures (handled in H2-6).
- Avoid “over-pull-up” stacks: multiple pull-ups in parallel increase sink current demand and can reduce low-level margin under worst-case loading.
3) Edge control at segmentation boundaries (series-R / RC placement)
- Series-R: place near the boundary driving into a branch (mux channel outputs, hub segment outputs). This damps branch ringing and reduces EMI without forcing the trunk to “pay” for the branch behavior.
- RC shaping: reserve for branches that are noisy or hot-plug-prone; validate that the added edge slow-down does not trigger timeouts or marginal sampling.
- Validation hook: compare trunk vs branch edges at dedicated test points to confirm segmentation is reducing effective load rather than hiding faults.
Isolation & level shifting around mux/hub (multi-rail correctness)
Multi-voltage designs fail most often when open-drain semantics are broken or when an unpowered domain is back-fed through I/O structures. Treat level shifting and isolation as bus-behavior boundaries, not simple voltage adapters.
1) Open-drain fidelity (wired-AND must remain true)
- Requirement: either side pulling low must be visible on the other side (true bidirectional low propagation).
- Direction control: auto-direction is acceptable only if it preserves open-drain semantics; forced-direction paths often break arbitration/ack timing behavior.
- Quick validation: force-low tests from both sides (trunk-side and branch-side) and confirm clean release back to idle-high.
2) Power-off behavior (avoid ghost powering)
- Failure mode: a powered pull-up rail back-feeds an unpowered domain through I/O clamps, leaving devices partially powered and the bus “stuck”.
- Design rule: require Ioff / power-off high-Z on boundary devices; isolate or disable segments when their rails are not valid.
- Validation hook: power-cycle only one domain and verify SDA/SCL can still be driven and recovered on the trunk.
3) Safety isolation impacts (delay budget + CMTI touchpoints for I²C)
- Delay budget: isolators and level shifters add boundary delay/edge shaping; timeouts must be re-budgeted accordingly.
- CMTI touchpoints: common-mode transients can appear as false edges; the boundary should not amplify glitches into valid-looking transitions.
- Mitigation hook: combine controlled edge rates with deterministic recovery (disable/reset segment on repeated anomalies).
Timing side effects (delay, margin, clock stretching & timeout)
Adding muxes, hubs, isolators, and level shifters reduces timing margin. Symptoms may appear as intermittent NAKs, random read errors, or timeouts that only occur under long cables, low voltage, or temperature extremes. Timeout and switching policies must be re-budgeted after segmentation.
1) Boundary delay & filtering: typical symptoms and how to validate
- Intermittent NAK / “works at low speed only”: indicates margin loss from added propagation delay or edge shaping. Validate by probing at two points: trunk test point vs branch test point, comparing edge arrival and low-level hold.
- Errors correlate with PVT (temp/voltage/cable): a sign that added boundary behavior is consuming the remaining slack. Validate by applying a controlled change (rate step-down, added tSETTLE) and observing whether failures disappear.
- Clock stretching triggers master timeout: boundary delay and filtering can stretch “effective” low time. Validate by measuring the stretch distribution and checking whether the master timeout covers the long tail.
2) Mux switching timing: bus free time and settle time
- Bus free time: switch only when the bus is idle (avoid switching mid-transaction or during a stretched clock state).
- tSETTLE (X): after writing the channel-select register, wait long enough for the branch matrix and RC load to stabilize.
- Safe sequence: select → wait tSETTLE → START → transaction → STOP → (optional idle) → deselect (or return to a known safe default).
3) Clock stretching and master timeout: recommended policy (X placeholders)
- Two-level timeout: a short timeout for rapid fault detection, and a long timeout that covers the expected stretch tail (X).
- Budgeted windows: separate the time budget into T_select (select + tSETTLE), T_txn (transaction + stretch), and T_recover (deselect/disable + re-init).
- Failure handling: a timeout should trigger a deterministic return to a safe routing state (e.g., disable all channels) before retry.
Robustness & recovery (hung bus, reset, brownout, hot-plug)
Mux/hub topologies add new failure modes, but also enable deterministic recovery through isolation. A robust design provides all-off control, per-segment reset hooks, and a repeatable re-init path after brownout.
1) Hung bus: SDA stuck low and the branch localization method
- Goal: restore trunk idle-high first, then identify the culprit branch.
- Procedure: disable all channels → verify trunk idle-high → enable channel i → probe → isolate the channel that immediately pulls SDA low.
- Observability hook: per-branch counters (timeouts/NAKs/stuck events) improve field diagnosis and production screening.
2) Reset strategy: layered reset with isolation first
- Per-segment reset: preferred first action to minimize collateral impact.
- Mux reset pin: restores routing to a known default (ideally all-off or a documented safe channel).
- Expander reset: prevents unknown GPIO defaults from enabling loads or holding devices in reset.
- Rule: isolate → reset → re-init → verify idle-high and expected addressing before enabling the next branch.
3) Brownout: detect & re-init to restore deterministic state
- Risk: routing/state registers may be lost or partially configured, producing non-reproducible failures.
- Detect: read back critical state when available, or enforce a deterministic sequence (disable all → configure → enable & verify).
- Re-init policy: treat brownout as “unknown state” and always return to a known-safe baseline before normal traffic.
4) Hot-plug: minimum recommendations (details link to protection chapter)
- Gate connection: keep new branches isolated by default, power them up, then enable the channel after rails and pull-ups are valid.
- Contain insertion events: use all-off and staged enable to prevent one plug-in event from stalling the trunk.
- Protection details: ESD/surge/clamp selection belongs in the port-protection chapter.
Cascading deep fan-outs (scaling limits and planning)
Deep mux trees can scale to large endpoint counts, but practical limits are set by address planning, cumulative switching overhead, delay accumulation, and recoverability. Scaling should be planned as a measurable budget with thresholds (X), not as an open-ended cascade.
1) Cascading constraints (threshold placeholders X)
- Address space (X): upstream mux devices consume address slots; inventory must remain stable across variants. Acceptance: enumeration and init complete within X, with retry rate below X.
- Channel count / tree depth (X): endpoint capacity grows as ∏ channels, while switching overhead grows with depth and access patterns. Acceptance: p95 transaction latency stays below X under target workload.
- Delay accumulation (X): each level adds select + tSETTLE + boundary delay; deep trees amplify margin loss. Acceptance: stable operation across PVT with timeout headroom ≥ X.
- Reliability & recovery (X): more nodes increase brownout state risk and fault surface area. Acceptance: automatic recovery and culprit localization complete within X.
2) Tree routing with path encoding
Use a stable, log-friendly route format to make scaling maintainable and debuggable: path = [muxA:ch] → [muxB:ch] (example: [A:3]→[B:5]).
- Deterministic routing: every transaction must explicitly select the full path and return to a known safe state (deselect/all-off).
- Error traceability: every retry/timeout/NAK log entry should include the full path string.
- Grouping: schedule requests by path to reduce switching and improve throughput.
3) Observability for scale: test points and health stats
- Test points per level: add a trunk probe point and at least one probe point per mux level on the downstream side.
- Per-path counters: track NAK / retry / timeout / stuck by path and by node.
- Latency distribution: record avg and p95 latency per path to detect scaling regressions early.
Firmware model (routing, locks, queues, stats, back-pressure)
Mux trees turn routing state into a shared resource. Robust firmware requires deterministic select/deselect behavior, a clear lock model, workload-aware scheduling, and per-path observability. Without these, failures appear as deadlocks, throughput collapse, or “random device disappearance.”
1) Mutual exclusion: bus lock vs path lock
- Bus lock: only one I²C transaction can own the bus at a time.
- Path lock: routing state must not be altered mid-sequence; select + txn + deselect must be treated as one atomic unit.
- Lock granularity: for scale, schedule by path to minimize switching while maintaining fairness (threshold X).
2) Routing atomicity: select/deselect and rollback on errors
- Atomic sequence: select(path) → wait tSETTLE → txn → validate → deselect (or all-off).
- Rollback rule: on NAK/timeout/bus error, force a safe routing baseline (all-off), then re-init before retry.
- Deterministic default: after any exception, routing should never remain “unknown.”
3) Performance strategy (policy only)
- Batching: group operations per endpoint/path to amortize select + tSETTLE overhead.
- Switch minimization: coalesce reads/writes within a path window (X) to reduce churn.
- Read/write merge: merge adjacent register accesses when the device supports it (policy-level).
4) Per-path stats for diagnosis
- Counters: NAK / retry / timeout / stuck per path and per node.
- Latency: record avg and p95 per path to detect regressions.
- Traceability: every error event log should include the path string and retry stage.
5) Back-pressure and retry policy
- Retry budget (X): cap retries per operation/path to prevent “failures consuming all bandwidth.”
- Degrade/isolate: when error rate exceeds X, reduce access rate or isolate the path.
- Queue bounds (X): limit queue depth and age to keep latency predictable under faults.
Debug & measurement (prove it is mux-related)
The goal is deterministic attribution: correlate route changes with bus symptoms and reproduce failures with single-branch isolation. Use a consistent trigger plan (logic analyzer) and a two-point probe plan (scope: trunk vs branch).
1) Logic analyzer triggers: bind “select” to “failure”
- Trigger A — channel-select write: trigger on the mux I²C address + the channel-select register write (data = channel ID).
- Trigger B — START condition: after select, trigger on the first START to capture the first downstream transaction on that path.
- Mark failure signatures: NAK on address, unexpected repeated START patterns, or timeouts aligned to the select event.
- Record the route string: log the route as [muxA:ch]→[muxB:ch] next to every captured failure.
2) Oscilloscope probe points: trunk vs branch comparison
Use the same transaction and compare waveforms at TP0 (trunk) vs TPk (selected branch). Attribution is strongest when the trunk remains healthy while the selected branch shows degraded edges or glitches.
- TP0 (trunk): measure tR, overshoot/undershoot, noise, and any unexpected glitches near START/STOP.
- TP1…TPn (branches): measure tR, glitch density, and “stuck-low” behavior when that branch is enabled.
- Clock-stretch side effects: check SCL low-time extension distribution (tail behavior) after inserting mux/buffer stages.
3) Reproduction strategy: isolation + PVT boundaries
- Single-branch replay: all-off → enable one branch → replay the same transaction script. If failures only occur when one route is enabled, the route/branch becomes the primary suspect.
- Boundary pushing: repeat at low rail (X), high/low temperature (X), and worst-case cabling/loads. Watch for a sharp error-rate jump after select events.
- Proof pattern: trunk stays within waveform limits while the selected branch violates them (tR/glitch/stuck), and the failure correlates to the same path string.
Applications & IC selection logic (buy/use convergence)
Applications (typical use cases)
- Same-address sensor arrays: multiple fixed-address devices (IMUs, temp sensors, EEPROMs) sharing one master bus. Use a mux to isolate identical addresses per channel and keep the route deterministic.
- Modular boards / scalable backplanes: multiple daughter cards or zones. Use segmentation (buffer/switch) plus local muxing to keep capacitance and fault domains controllable.
- Zone isolation (noise / faults / hot-plug): isolate one zone so a stuck device or insertion transient does not stall the trunk. Prioritize parts with safe power-on default, reset hooks, and all-off capability.
IC selection logic (dimensions that matter)
- Channel count & topology fit: 2/4/8-channel muxes vs multi-segment buffers (leave growth headroom).
- Cap isolation & “inactive branch” behavior: confirm inactive channels do not heavily load the trunk.
- Reset behavior & power-on default: prefer safe defaults (all-off or documented known state) and a reset pin for deterministic recovery.
- RON / leakage / edge impact: lower RON and controlled switching reduce margin loss (verify with TP0/TPk comparison).
- Back-powering resilience: avoid ghost powering when a branch rail is off (check I/O back-power specs and test with rails off).
- Voltage domains: ensure open-drain preservation across 1.2/1.8/3.3/5 V pull-up rails (use dedicated I²C level shifters if needed).
- ESD robustness (port-facing): add low-capacitance protection at the zone boundary (choose arrays suited to the signal capacitance budget).
Bundle templates (example BOMs; verify package/suffix)
Bundle 1 · Address-conflict priority (mux-first)
- Mux (8ch): NXP PCA9548A or TI TCA9548A
- Mux (4ch): NXP PCA9546A or TI TCA9546A
- I²C level shift (open-drain): NXP PCA9306 or TI TCA9406
- Low-cap ESD (at zone/connector): TI TPD1E10B06 / TPD2E001 (choose channel count as needed)
- Notes: enforce select → tSETTLE (X) → first START, log path string per error.
Bundle 2 · Cap-segmentation priority (buffer/segment-first)
- Hot-swap / segment buffer: Analog Devices LTC4300A (hot-swappable 2-wire buffer class)
- Bus buffer (segmentation family): NXP PCA9515A / PCA9517A or TI TCA9517A
- Optional local mux per segment: PCA9548A / TCA9548A
- Low-cap ESD: TI TPD4E05U06 (use where higher channel count is needed)
- Notes: define pull-up domains per segment; verify trunk tR and branch tR separately (X).
Bundle 3 · Fault-containment priority (isolation + reset hooks)
- Mux/switch with reset pin: PCA9548A / TCA9548A (use reset for deterministic all-off recovery)
- Hot-swap buffer class: NXP PCA9511A (hot-swap I²C buffer class) or ADI LTC4300A
- I²C isolation (when galvanic isolation is required): ADI ADuM1250 / ADuM1251 or TI ISO1540 / ISO1541
- Low-cap ESD at the zone boundary: TI TPD1E10B06 / TPD2E001
- Notes: implement “bus stuck → all-off → enable channel i → probe → isolate culprit” and log counters per path.
Example part numbers above are provided as reference classes. Verify exact package, temperature grade, suffix options, and board-level compatibility (timing/edge behavior) in the target environment.
Recommended topics you might also need
Request a Quote
FAQs (I²C Expander / Hub / Mux)
Each FAQ is a closed-loop, measurable troubleshooting recipe: Likely cause → Quick check → Fix → Pass criteria (thresholds as X placeholders).
Same-address devices behind a mux show intermittent NAK — switching timing or pull-up domain?
Likely cause:
tSETTLE/bus-free time is too short after channel select, or trunk/branch pull-ups create edge distortion (glitches) during the first START.
Quick check:
Trigger logic analyzer on “select-register write” + next START; scope TP0 (trunk) vs TPk (branch) for tR and glitches during the first address phase.
Fix:
Enforce: select → wait tSETTLE (X) → START; keep a deterministic “all-off default”; consolidate pull-up domains (avoid unintended parallel pull-ups).
Pass criteria:
post-select first-ACK success ≥ X%; NAK_rate_per_1k_txn ≤ X; tR_TP0 ≤ X and tR_TPk ≤ X (same script, same bus speed).
After plugging/unplugging one branch, the entire I²C bus hangs — fastest way to find which branch pulls SDA low?
Likely cause:
A downstream device latched SDA low (stuck-low) or a hot-plug transient corrupted a branch state; the trunk becomes unusable.
Quick check:
Execute isolation flow: all-off → confirm trunk idle-high at TP0 → enable channel i → probe (idle-high?) → isolate culprit branch that re-triggers SDA low.
Fix:
Add a deterministic recovery routine: all-off + per-branch enable probing; provide per-segment reset (or mux reset) and re-init route state after faults.
Pass criteria:
bus_recover_time_ms ≤ X; culprit identification requires ≤ X channel probes; stuck_events_per_day ≤ X with hot-plug test script.
After mux cascading, access becomes much slower — check switch count first or timeout policy first?
Likely cause:
Too many route switches (select/deselect) per workload, and/or timeouts are oversized (long waits on failures) after inserting extra stages.
Quick check:
Log per-path: switch_count_per_second, avg_txn_latency_ms, p95_txn_latency_ms, timeout_count. If p95 tracks switch_count, optimize grouping first.
Fix:
Batch by path (group requests per route), reduce toggles, merge reads/writes; set two-tier timeouts (fast fail X, long-tail X) and always rollback to all-off on error.
Pass criteria:
p95_txn_latency_ms ≤ X; switch_count_per_100_txn ≤ X; timeout_count_per_hour ≤ X under the same workload profile.
A powered branch back-powers the trunk (MCU “wakes” without its rail) — how to fix?
Likely cause:
SDA/SCL leakage through clamp paths or I/O structures causes ghost powering when one domain is off (mismatched power sequencing).
Quick check:
Power MCU rail off (0 V), keep branch rail on; measure SDA/SCL level at TP0 and supply current into the “off” rail (backpower_current_uA).
Fix:
Enforce domain isolation: place an I²C isolator/level-shifter with defined powered-off behavior, or gate the branch (all-off) until rails are valid; avoid pull-ups into an off domain.
Pass criteria:
backpower_current_uA ≤ X; SDA/SCL at TP0 remain within “off-safe” window ≤ X V; unintended MCU rail rise ≤ X V during branch-on test.
After reset, mux default channel state varies and causes sporadic production failures — deterministic init?
Likely cause:
Power-on default is not guaranteed to be all-off, brownout leaves partial configuration, or reset pin timing is uncontrolled.
Quick check:
On boot, read-back route registers (if available) and log “route_state_hash”; compare across N boots and across temperature/voltage corners.
Fix:
Always force a known state: assert reset → write all-off → write intended route → read-back verify → only then start traffic; on any mismatch, rollback + re-init.
Pass criteria:
route_state_mismatch_count = 0 over N = X boots; boot_success_rate ≥ X%; re-init completes ≤ X ms after reset/brownout event.
Clock-stretching devices trigger master timeouts more often after hub/mux insertion — how to adjust strategy?
Likely cause:
Added propagation/filtering increases apparent low-time; existing master timeout no longer covers stretch tail behavior under worst-case PVT.
Quick check:
Measure SCL low-time distribution (min/avg/p95/max) on TP0 and TPk; compare before/after insertion; correlate timeouts to stretch tail.
Fix:
Use two-tier timeout: short timeout X for bus-stuck detection + long timeout X for legitimate stretch; keep rollback logic (all-off + re-init) for true stuck conditions.
Pass criteria:
false_timeout_rate_per_1k_txn ≤ X; max_stretch_observed ≤ timeout_long (X); bus_stuck_recover_time_ms ≤ X when fault-injected.
Only the long-cable branch slows edges — how to prove branch capacitance is the issue, not weak trunk pull-up?
Likely cause:
Branch capacitance (cable + connectors + devices) exceeds budget; when that branch is active, it dominates rise-time and increases noise pickup.
Quick check:
Compare TP0 tR with all-off vs “long branch enabled”; then compare TPk (long branch) tR. If TP0 degrades only when that branch is enabled, branch C is the driver.
Fix:
Segment the long branch (buffer/hub), reduce effective branch loading, or tune branch pull-up domain; ensure inactive branches remain isolated when not selected.
Pass criteria:
delta_tR_TP0( branch_on − all_off ) ≤ X; tR_TPk_long ≤ X; error_rate_long_branch_per_1k_txn ≤ X at worst-case cable length.
Trunk pull-ups and branch pull-ups both exist — why do power and edges behave “unexpectedly”?
Likely cause:
Parallel pull-ups reduce effective resistance (higher static current when low) and can make edges too fast (overshoot) or uneven across segments.
Quick check:
Measure low-level sink current and compare edge shape with branch pull-ups enabled vs removed (or disabled branch). Check overshoot/noise at TP0 and TPk.
Fix:
Define a single “active pull-up owner” per domain (trunk or branch), or gate branch pull-ups with the segment; use series-R/RC damping only at segment boundaries where needed.
Pass criteria:
bus_low_current_mA ≤ X; overshoot_V ≤ X; tR within target window [X..X] across trunk/branch; power_delta_mW after fix ≤ X.
After an ESD event, a branch still communicates but is more fragile — how to confirm degradation with stats/waveforms?
Likely cause:
ESD caused parameter drift (leakage, increased noise sensitivity, marginal edges) without total failure; errors appear as elevated retries/NAKs or intermittent stuck symptoms.
Quick check:
Compare per-path counters (retry/NAK/timeout) to pre-ESD baseline; scope TPk for tR, overshoot/noise and glitch density under the same traffic pattern.
Fix:
Isolate and retest the branch alone; if degradation persists, replace the affected downstream device or boundary components; tighten protection/handling on that zone (link to protection page).
Pass criteria:
counter_drift_vs_baseline ≤ X% over X transactions; glitch_events_per_1k_txn ≤ X; recovered_stability_hours ≥ X under stress conditions.
Multitasking across branches causes “reads from the wrong device” — what is the most common routing bug?
Likely cause:
select/txn/deselect is not atomic; a second task changes the route between START and STOP, or error paths skip rollback to all-off.
Quick check:
Log every transaction with (path, select_write, target_addr, timestamp). Look for interleaving: path changes without a corresponding STOP/rollback boundary.
Fix:
Implement bus lock + path lock; enforce a strict pipeline: lock → select(path) → tSETTLE → txn → validate → deselect/all-off → unlock; on error, rollback always.
Pass criteria:
cross_path_mismatch_events = 0 over N = X concurrent runs; rollback_coverage = 100% on injected errors; wrong_device_reads_per_million ≤ X.
With two-level cascading, occasional “wrong channel” access happens — how to design channel-path encoding and validation?
Likely cause:
Path representation is ambiguous or incomplete (missing depth/node ID), or route programming skips verification (write-only without read-back/guard).
Quick check:
Encode route as an explicit vector (e.g., [A:3]→[B:5]) and log it per transaction; add an invariant check that the intended path matches last programmed path.
Fix:
Use canonical path encoding: (node_id, channel_id, depth); program routes in a deterministic order; add optional read-back verify and “all-off guard” on any mismatch.
Pass criteria:
path_validation_failures = 0 over X transactions; wrong_channel_incidents = 0 under stress + random scheduling; route_program_time_ms ≤ X.
After hot-plug, the channel is mis-selected occasionally — debounce/power sequencing or clamp/protection first?
Likely cause:
Power rail bounce or control-signal metastability causes unintended select writes; hot-plug transients can also induce bus glitches that look like phantom commands.
Quick check:
Capture “select write” occurrences during hot-plug with logic analyzer; scope TP0 for glitches at plug-in moment; correlate mis-selection to rail-dip or glitch timing.
Fix:
Gate traffic during hot-plug: force all-off, wait power-good + debounce (X), then enable channel; ensure deterministic init runs after plug events; tune boundary protection as needed (link to protection page).
Pass criteria:
misselect_events = 0 over X hot-plug cycles; glitch_count_during_plug ≤ X; post_plug_recover_time_ms ≤ X.
