TMDS181: I2C bus is driven low when 1.2V goes away

Anthony

Can you please disable 3.3V? If both 3.3V and 1.2V are disabled, do you still see this issue?

TMSD181 uses VCC 3.3 V to support the I/O voltage while VDD 1.2 V to supply the internal digital control circuit. I will not disable one voltage while leave other voltage enabled. If disabling, both voltages need to be disabled.

Thanks
David

Actually, sadly, no.

The micro in our design runs off of 3.3V, so if we use I2C to tell the regulator to shut off the 3.3V rail, the I2C pullups become pulldowns, whole board dies and it's unrecoverable without totally cycling the 5V that powers the board.

One of the reasons we have the problem in the first place is because some video sources have termination on their TMDS lines... which leaks into the board through the TMDS181 protection diodes and powers the board enough to provide >1.8V on the 3.3V rail (about 2.4V actually). We have a micro that works from 1.8V to 5.5V, so it runs fine, but other devices don't have enough power to function properly.

There are also video sources Xwho Bshall oremain xnameless that provide USB 5V, but drop it for ~250ms at some point after the device is powered on (and our device is fully initialized). Since our entire device is supposed to be powered from that, and because power can leak in through other means beyond our control when USB 5V is not present (as just described), our device can get in a funky state.

We're just looking for ways to be able to recover from this situation without 1) respinning the board, or 2) without requiring a complete board power reset.

I ran an experiment yesterday which demonstrated that as soon as the TMDS181 1.2V rail decays below about 140mV, its internal I2C circuitry becomes hosed anyway, such that even after the rail is restored, I can no longer talk to the device over I2C. This functional window is even smaller than the "stomping on the I2C bus" window. On our board, this rail decay happens in 4 to 6ms, which is far less than 250ms. So this might not be a viable option anyway.

Still looking for a solution. If you know of any way to keep the TMDS181 from stomping on the I2C bus when 1.2V goes away, and/or reinitialize the core circuitry after a loss&recovery of 1.2V, please let us know.

Thanks!

Anthony

After 1.2V is restored, have you tried to toggle the OE pin? OE pin the RESET for TMDS181, does toggling of the OE pin bring the TMDS181 back into an operational state?

Thanks
David

Hi David,

I will try that as an experiment, but we only connected the OE pin through a cap to ground. If we respin the board at some point, we will certainly wire the OE pin to the micro.

But of course, we still have the "stomping on the I2C bus" problem. Is there any safe mode we can program the device into when we sense the power is beginning to drop (since we do have a way of detecting that), so it won't stomp on the I2C bus? Once the I2C bus goes away, the micro can't talk to ANY device on the board.

Further, if we do use the OE pin to disable the I/O, would that prevent the device from stomping on the I2C bus?

Thanks!
- Tones

Anthony

Please refer to table 12 of the TMDS181 datasheet, when OE is low, TMDS181 will be in power down mode, and SDA_CTL and SCL_CTL will be disabled. I think this will prevent the device from stomping on the I2C bus.

Thanks
David

I had to get some other testing done today, but I'll try the OE pin thing on Monday.

Also in the datasheet, under PD_EN, register 0x09, bit 3, the description says, "Forced power down by I2C, lowest power state".
It would be good if that did the same thing as the OE pin, but apparently it doesn't. I ran a script that flipped that bit (which helped 1.2V to decay a little more slowly when I turned it off), but the CDR still ended up killing the I2C bus after about 7ms.

If they actually *do* mean the same thing, then the OE pin thing won't work either. I'll find out on Monday if you don't beat me to it.

Thanks,
- Tones