TCA9554: Question about Reset and active I2C CLK / DATA Signals

Hi Rich,

Richard Bair said:

I'm experiencing an occasional lock/latch of this part when I write to it and the part issues and ACK; however, it did not process the written data.  Then I subsequently read from it and it will only show all IOs as 0 (logic LOW) which matches the output pins.  It's as if the write was ignored. I also do not think I have issues with proper HIGH / LOW voltage levels during the write.

The device should not latch / risk damage / latch up / cause improper reset, when VCC = 0 V and I2C is present on SDA/SCL. 

Do you have a scope capture of what is being written to the device? 

When you say "lock/latch", the TCA9554 IO_x pins are configured to OUTPUT and output a logic LOW signal? Each I/O is pulled up to VCC internally through a 100k PU resistor. 

Regards,

Tyler

I actually have 2x of the TCA9554s.  The one shown above drives a Darlington IC (all outputs). What I'm seeing is that if I have resets near/during active I2C comms typically we have an improper read check afterwards and start the recovery process by resetting again and often it will recover.  However, occasionally it will not recover.  In this second case, when I send output write commands they appear to be ignored and a subsequent read shows 0s for all IO (like the write was ignored).  This attached is an example of showing entering into the recovery process.

- This shows CLK (purple), DATA (blue), and a manual injection of CS544-MCIRST

I'm unable to recover from this second state until I issue  third reset.

Thanks,

-Rich

So above shows reset release during 12C comms (manual via switch). Then subsequent I2C comms can behave as I described above where WR seems to be ignored.  Hope this sequence is making sense. 

Hi Richard,

And when you "reset" the device, you are powering down the chip and then back up through the MCU_RST? 

Do you have a photo of the top-side marking of this device?

Is the issue present across multiple IC's? 

Regards,

Tyler

Here's a top side pic:

So we migrated this circuit from a PCA9654 part to this TCA9554 back in May 2025.  Since that time I'm aware of ~9x field issues where I have to POR to recover over maybe 3k units so far. Prior to that I'm not aware of an issue. We have the ability to reset the part via control of Vcc and I noticed we may not be honoring the rise time (see first post schematic for our VCC gating). The PCA9654 datasheet does not have the POR timing as detailed in the TCA9554 datasheet. We tried to elongate the rise time to >100us today via a series resistor but that did not seem to resolve the issue.  It does not happen every boot or when I manually force the C554_MCURST signal low but if I reset the part 50x on units that exhibit the issue I may have 3-4x failures where I2C write command is ACK'd by the part but a subsequent read suggests the prior write command was not processed.

I noticed some of my pics are the same...adding block diagram again for first post.

Hi Rich,

This is interesting. Replacing PCA9554 with TCA9554 should only benefit your system since TCA9554 is the upgrade. 

So switching from PCA9554 to TCA9554 has resulted in over 9x field issues. 

The main problem is a power-on reset occurs during an I2C transaction. After powering back up again, you can write properly through the i2C bus, of which the TCA9554 ACK's. But the read back on the I2C bus is incorrect. 

Can you provide a scope capture of SDA and SCL when you issue a write command? 

Scope capture when you issue a read command? 

Richard Bair said:

We have the ability to reset the part via control of Vcc and I noticed we may not be honoring the rise time (see first post schematic for our VCC gating)

You added a series resistor to increase rise time within spec. 

Can we confirm that the measured voltage at the VCC pin is following the power-on reset requirements shown in figure 31 of the TCA9554 datasheet? 

In the waveform that you provided above: 

Is CH1 the voltage at CS54-MCU-RST or is it the voltage at the VCC pin? I want to double check we are following figure 31, however, we need the scoped voltage at the VCC pin, not the voltage at the MCU-RST output. 

Richard Bair said:

I noticed some of my pics are the same...adding block diagram again for first post.

Just to double check, I noticed two TCA9554's on the same I2C bus. 

Can we confirm that both have unique i2c addresses? 

Regards,

Tyler

- Switching from PCA9654 (not PCA9554)...I may have that wrong somewhere (sorry):

- So far, my Fault Tree is very focused on the reset circuit...I will work to capture falling, width and rising of original circuit and with series resistor (where we believe we meet the rising spec) later today

- I will work to have the I2C write, ACK and following I2C read where data is all 0 from the read later today

- Also, yes, there are 2x IO expanders

• 1x has A2 pulled high via 10k, A0 and A1 pulled to GND via 10k
• 1x has A2, A1 and A0 pulled to GND via 10k

Hi Rich,

Thanks for the update. Looking forward to the lab results. 

Regards,

Tyler

Another quick observation.  If we remove C18 and manually exercise the C554-MCURST the issue occurs every time.  We changed C18 from 0.1uF to 2.2uF same stimulus does not seem to create the issue. Reference only for now but making us think glitch sensitivity issue.

Tyler Townsend , also can you confirm that this device does or does not have the general software reset command 0x00 address and 0x06 data? Just want to know if we have other options.  I did not see anything in the datasheet but have not tried it yet. Traces being worked on.

Hi Rich,

I will respond shortly. 

Regards,

Tyler

Hi Rich,

C18 is directly connecting to VCC pin of the I/O expander. Removing C18 would cause faster discharging time when MCU_RST is manually toggled. I assume the voltage on the VCC pin is potentially glitching causing an unsuccessful power-on reset. Adding a larger decoupling cap will increase rise/fall time at the VCC pin and will give a much smoother transition when pulling LOW or charging back to 5 V. 

This makes me think if we scope the VCC pin directly, we might see that the voltage on VCC is not following the power-on reset requirements to the datasheet which could cause incorrect initialization to the device. This might be why read backs fail after a power cycle since the power cycle did not properly reset the device. 

No general call software reset on this device. Only our TCAL I/O expanders have this feature implemented. 0x06 data should NACK since the register map only is from 0x00 to 0x03. 

Regards,

Tyler