Designing IO Domains That Don’t Fight Each Other

In multi-voltage embedded systems, the most common instability does not come from firmware bugs.

It comes from IO domains quietly fighting each other.

Modern boards rarely operate on a single logic level. A typical sensor platform may include:

• 3.3V MCU domain
• 1.8V sensor IO domain
• 2.8V analogue sensor rail
• Open-drain buses
• High-speed digital interfaces

If these domains are not deliberately isolated and sequenced, they interact in subtle, damaging ways.

The system may appear functional — until temperature shifts, brownouts occur, or startup timing changes slightly.

At Hoomanely, we stopped treating IO voltage compatibility as a checkbox.
We treat it as architecture.

Because voltage domains are not just electrical levels.
They are behavioural boundaries.

The Hidden Problem: Mixed-Voltage Assumptions

In many conventional designs:

• A level shifter is placed between 3.3V and 1.8V.
• Pull-ups are added.
• The schematic passes review.
• The board boots.

But during real operation:

• IO pins power up at different times.
• Pull-ups activate before rails stabilise.
• Sensors partially bias through protection diodes.
• Bidirectional buses experience injection currents.
• Edge rates differ across domains.

The issue is rarely visible in static design review.
It emerges during transient states.

And transient states define reliability.

IO Injection: The Silent Silicon Stress

When a higher-voltage domain drives a signal into a lower-voltage domain that is not yet powered, current flows through internal protection structures.

This causes:

• Back-powering of unpowered rails.
• Partial biasing of analogue blocks.
• Increased leakage current.
• Long-term silicon stress.
• In extreme cases, latch-up.

The system may still function.

But the stress accumulates.

We eliminated this by designing IO boundaries deliberately.

Level Shifting Is Not Enough

A level shifter alone does not guarantee isolation.

Key considerations we implement:

• Direction-aware translators instead of passive bidirectional devices.
• OE (Output Enable) gating tied to rail validity.
• Separate pull-ups per voltage domain.
• Controlled edge rate where necessary.
• Clear ownership of bus mastership.

This transforms IO from “connected” to “architected.”

OE Gating: Enabling Only When Valid

We ensure that level shifters are enabled only when:

• Both source and destination rails are stable.
• Reset domains are in defined states.
• Downstream sensors are not in partial bias conditions.

This prevents:

• Phantom powering during ramp.
• Bus contention during reset.
• Glitch propagation across domains.

The IO path exists only when both domains are electrically valid.

Open-Drain Buses and Pull-Up Discipline

I²C buses are especially vulnerable.

Common mistakes include:

• Shared pull-ups across domains.
• Pull-ups connected to a rail that ramps slowly.
• No consideration of rise-time vs voltage threshold.

We implement:

• Domain-specific pull-ups.
• Pull-up rails validated before release.
• Clean routing to minimise parasitic capacitance.
• Explicit bus idle state validation during boot.

This eliminates bus lockups that originate before firmware runs.

Physical Layout Reinforces Logical Isolation

Voltage domain separation is not only schematic-level.

We reinforce isolation through:

• Clear analog vs digital ground strategy.
• Dedicated return paths.
• Minimal cross-domain trace coupling.
• Avoidance of shared high-speed and low-speed reference planes.

Electrical behaviour follows physical routing.

A well-drawn schematic with poor layout is not isolation.

Practical Improvements We Observed

After restructuring IO domain architecture, we measured:

Reduced Startup Bus Errors

I²C and sensor initialisation failures during cold boot were eliminated.

Lower Leakage During Partial Power

Back-power injection currents were removed, reducing unintended rail biasing.

More Predictable Brownout Recovery

When rails dip momentarily, domains return cleanly without undefined latch states.

Cleaner Signal Integrity

Edge rates stabilised due to proper domain separation and controlled pull-up configuration.

Reduced Long-Term Stress on MCU Pins

No more repeated injection through protection diodes during ramp cycles.

These improvements do not show up in a feature list.

They show up in durability.

Conventional IO Design vs Structured IO Architecture

Conventional Approach:

• Add generic level shifter.
• Connect pull-ups.
• Assume compatibility.
• Handle glitches in firmware.

Hoomanely Approach:

• Define domain boundaries clearly.
• Gate level shifters with rail validity.
• Separate pull-ups by voltage domain.
• Control IO enable timing.
• Validate startup transitions with scope measurement.
• Ensure no IO path exists during partial rail states.

The difference is architectural intent.

Designing for Brownout and Recovery

Voltage dips are inevitable in real systems.

If IO domains are not properly isolated:

• One domain collapses faster than another.
• Protection structures conduct unexpectedly.
• Buses freeze.
• Sensors remain in undefined states.

We ensure:

• Rail supervisors enforce reset before unsafe voltage thresholds.
• Level shifters disable automatically during rail collapse.
• IO lines return to known bias states.
• Recovery path is deterministic.

The system does not depend on firmware to clean up electrical instability.

Why This Matters More in Sensor Systems

Sensor-heavy platforms combine:

• Analog bias circuits.
• High-speed digital lanes.
• Precision timing blocks.
• Mixed-voltage logic.

An unstable IO boundary can:

• Distort sensor readings.
• Introduce timing jitter.
• Trigger spurious interrupts.
• Corrupt initialisation sequences.

Stability at the voltage boundary preserves integrity at the data layer.

The Core Principle

An IO connection should only exist when both sides are electrically valid.

If one side is unstable, the boundary must be closed.

That principle drives:

• OE gating.
• Reset alignment.
• Rail sequencing.
• Pull-up control.
• Brownout management.

We do not rely on firmware to correct hardware ambiguity.

We prevent ambiguity.

Designing IO Before Writing Code

Our methodology enforces:

• Clear voltage domain documentation.
• Defined rail dependencies.
• IO ownership mapping.
• Startup and shutdown timing validation.
• Scope-based verification of ramp and release order.

If firmware crashes during boot, IO must remain safe.

If a sensor resets mid-operation, IO must not corrupt adjacent domains.

Electrical integrity precedes software logic.

Final Thought

Voltage domains are invisible in user-facing features.

But they define:

• Startup reliability.
• Long-term silicon health.
• Brownout behaviour.
• Signal integrity.
• Sensor accuracy.
• Product lifespan.

Designing IO domains that do not fight each other is not about compliance.

It is about respect for electrical boundaries.

And in embedded systems, respecting boundaries is the difference between a product that “works most of the time” and one that works every time.