Controlling I/O Expander Outputs Before Firmware Initialization

An I/O expander may control a relay enable, indicator, analog switch, or regulator long before application firmware finishes initializing it. The attached circuit must have an acceptable state during reset and bus startup. Define that interval explicitly instead of assuming the eventual programmed output value exists from power-on.

Read reset defaults by register

The Texas Instruments TCA9535 data sheet states that its I/O ports become inputs at reset and describes separate configuration and output registers. Its behavior differs from an expander with internal pull-ups or another reset architecture. Use the selected part’s register defaults and electrical specifications.

List each controlled function, active polarity, required startup state, external bias, and receiving threshold. Record the expander’s supply relative to the processor and controlled device. An input state at the expander does not guarantee a particular voltage at the external control node.

Design a deliberate initialization sequence

1. Establish acceptable external levels before serial communication begins.
2. Review the output-register value that will take effect when direction changes.
3. Choose a register-write order that avoids unintended control transitions.
4. Verify communication completion and handle a failed write.
5. Read back appropriate state without confusing input observation with output-latch contents.

For example, configuring a pin as an output before loading its intended inactive value can briefly apply the reset value of the output latch. Whether that matters depends on the receiver and actual transaction sequence. Check the data sheet and capture the control node rather than assuming the pulse is too short to have an effect.

Test unequal reset conditions

A processor reset may leave the expander powered and retain its previous register state. Conversely, an expander supply interruption may return its ports to inputs while the processor continues running. The software recovery policy must account for the power and reset domains actually present on the board.

Test cold startup, processor-only reset, expander power cycling where permitted, and communication failure. Observe the controlled function as well as the bus. A successful register read after recovery does not prove that the external output remained acceptable throughout the event.

Release the bias network, reset assumptions, initialization sequence, and fault response together. Keep them associated with the expander ordering code and firmware revision. When changing to a pin-compatible expander, compare reset defaults, pull structures, and register behavior explicitly. The goal is a defined control state during every relevant phase, including the period before the first successful I2C transaction.

Document any product variant that changes output polarity or omits an external bias component.