Hot-Plugged I2C Modules: Detect Partial Power and Avoid Probing an Unready Branch
Do not use the first I2C acknowledgement as proof that a newly inserted module is ready. Qualify the physical attachment, power sequence, buffer connection, and device initialization separately. Admit transactions only after those conditions belong to the same attachment instance, and revoke that permission immediately when the instance becomes uncertain.
Applicability: the concrete connection contract is Texas Instruments TCA4307 data sheet SCPS270B, revised November 2023. The proposed module lifecycle is hypothetical. Connector sequencing, supply control, pull-ups, and downstream devices require a board-specific electrical review; this article does not certify an arbitrary I2C connector for hot plugging.
1. Define the attachment boundary
Draw the backplane, connector, hot-swap buffer, module supply, and downstream devices. Identify which signals can make contact before power and ground, which supplies remain live, and what controls admission to the branch. A presence contact is useful evidence of insertion, but it is not a measurement of every downstream rail.
The TCA4307 data sheet recommends locating the buffer on the removable card. Its precharge benefit requires VCC before the bus contacts connect. EN low isolates the two sides but also disables precharge. Therefore, “hold EN low during insertion” is not automatically equivalent to the documented precharged insertion sequence.
Write down the chosen design explicitly. If an external controller holds isolation while power stabilizes, review what protects the contact event during that interval. If hardware permits automatic connection, software must still withhold device use until the remaining readiness conditions are met.
Audit every possible back-power path, including interrupt, reset, identification, and debug connections. The buffer’s powered-off high-impedance I2C-pin feature applies to that component’s specified pins; it does not establish safe partial-power behavior for the entire module.
2. Interpret READY narrowly
For this buffer, connection requires high OUT-side lines plus an IN-side idle or STOP qualifier. READY is an open-drain connection indication, not sensor power-good or initialization-complete. EN low and automatic stuck-bus disconnection both produce a disconnected state. These distinctions follow sections 4 and 7.4 of the data sheet.
Record READY alongside EN, module presence, and independently qualified power state. A low indication can mean the connection process is incomplete, intentionally disabled, or interrupted by a fault. It does not uniquely identify physical removal.
Likewise, a high indication says the buffer path is connected under its contract. It does not prove the target address is unique, a device has finished its internal startup, or the next register transaction will be accepted. Maintain separate evidence fields instead of collapsing all of them into one ready Boolean.
3. Use an explicit admission state machine
| Proposed lifecycle state | Evidence and permitted action |
|---|---|
| Absent or attachment uncertain | No new branch requests; invalidate the prior attachment instance. |
| Power qualifying | Observe the board’s presence and supply criteria; keep ordinary device traffic blocked. |
| Connection qualifying | Apply the reviewed EN policy and wait for valid connection evidence within a bounded deadline. |
| Device initializing | Allow only the documented identification and configuration sequence for the expected device. |
| Operational | Admit normal transfers while attachment, power and connection remain valid. |
These are software admission states, not a claim that EN must take one universal value in every row. The hardware’s insertion sequence remains authoritative. Record the specific EN and power-control behavior chosen for each transition in the board integration document.
Assign a new generation value whenever a module is removed, replaced, or reset through a lifecycle transition that invalidates outstanding work. Every queued request and completion carries that generation. A late completion from the previous module must not publish data into the new module’s state.
4. Probe only the expected device contract
Once the branch is qualified, perform the documented identity or capability check for the expected module. Avoid treating an arbitrary bus scan as a harmless readiness test. A transfer used for detection may have meaning to a different device or an incompletely initialized target.
The Linux v6.12 I2C device-instantiation guide distinguishes explicit device declaration from limited address-based detection and explains why detection is not a general substitute for enumeration. For a removable module, connect the platform’s lifecycle management to a known device description rather than repeatedly guessing addresses.
Serialize initialization with removal and normal requests. After each potentially sleeping transaction, confirm that the attachment generation and qualification state still match. If they do not, discard the result and follow teardown rather than completing initialization based on stale observations.
Successful identification still does not validate application data. Finish the device-specific reset, calibration, configuration, and first-valid-result checks appropriate to that part. Keep those checks separate from the buffer’s connection indication.
5. Handle disappearance during a transfer
A connector can open after admission but before completion. On presence loss, power fault, or unexpected connection loss, stop admitting new work and invalidate the instance. Let the controller’s supported cancellation, timeout, and recovery path establish when the in-flight transaction is no longer active.
Do not publish a partially received register set as a valid sample. Preserve the transport result, received length, generation, and observed lifecycle transition. A later successful retry belongs to a new validated operation; it does not retroactively make the interrupted one complete.
Use bounded retries tied to state. Repeatedly probing a disconnected or unpowered branch adds noise without proving readiness. If READY drops while presence stays asserted, investigate the buffer and bus condition before assuming the module was physically removed.
6. Verify insertion, partial power, and replacement
- Normal insertion: capture contact, supply, EN, READY, and the first admitted transaction.
- Power delayed: require traffic to remain blocked until the actual power criterion passes.
- Connection never established: expose a bounded qualification failure, without a probe loop.
- Removal during I/O: reject incomplete data and prevent old completions from reviving the device.
- Rapid replacement: verify that a new generation cannot inherit old configuration or cached identity.
Use a fixture designed for the intended contact sequence and fault conditions. Do not create arbitrary shorts or partial-power states on an unreviewed production assembly. Save waveforms with board revision and component versions so electrical and software observations can be compared.
No hot insertion or power-sequencing test was performed for this article. The deliverable is an attachment-generation admission contract: physical connection, valid power, connected buffer, and initialized device must all be established before ordinary traffic can be trusted.
