Experiments with resistance in the 5V power supply line to the TXS0102 have proven fruitless.

Values above about 3K allow everything on the 5V side of the I2C to run fine, but there is no communication on the 3.3V side.

Values below 1.2K start to allow communication on the 3.3V side, but it is unreliable.

Values below 680Ohms allow perhaps a little better communication on the 3.3V side, but kill all communication on the 5V side.

I've switched the OE (Output Enable) pin of the TXS0102 to be powered by 5V, instead of 3.3. To no avail.

We have another hacked up prototype that uses an ADAFRUIT 757 level shifter (https://www.digikey.com/product-detail/en/adafruit-industries-llc/757/1528-1007-ND/4990756) instead of the TXS0102.

This prototype behaves the same way. One thing that we can do with the ADAFRUIT part is actually desolder and replace pullup resistors internal to the level shifter.

We're also looking at the datasheet for the Focaltech FT5406 controller, which is what the touchscreen uses.

There are only two knowns right now:
-The motherboard has pullup resistors onboard, because we can operate the 5V I2C without any pullup resistance or level shifters (which have internal pullup resistance). So any pullup resistance that we apply
-The motherboards that work (all I2C, both 3.3V and 5V communicates) are among the first batch that we bought, with a revision 5.05. Later motherboards (revision 5.07) don't work. We have hacked BIOS and software to match, to no avail. So there is some hardware difference on the motherboard that is sensitive to our I2C design.

 

The motherboard has pullup resistors onboard, because we can operate the 5V I2C without any pullup resistance or level shifters (which have internal pullup resistance).

There's no need to guess. You can measure it. When 5V is present, get DMM in current mode and measure current between the line and the ground, then use the Ohm's law to calculate resistance. Clock and data lines may have different resistance.

So there is some hardware difference on the motherboard that is sensitive to our I2C design.

You can compare bad boards to good ones. Compare the signals on the scope. Measure pull-ups. See what's different. Then fix it.

 

@lastcowboy32
Maybe you could upload a portion of the PCB design (screenshot of the layers), of both revisions?

 

Now smacking my own forehead.

We've already compared quite a few scope signals between working/non working setups with little to show for it.

Measuring the pullups, though, might yield some kind of hard number that could point us somewhere. If we get the same measurement for working/non working motherboards, even that would be helpful to show that it's possibly some kind of level tolerance issue...as in, maybe they've upgraded a chipset with slightly different tolerances Vin(low) and/or Vin(high)

 

Pullup current measurement was 3.22mA on the board that doesn't work (Mitac PD10BI version 5.07). Pullup current measurement was 3.19mA on the board that does work (Mitac PD10BI version 5.05). Both boards drive the I2C on the HDMI with 5Volts. That gives me a pullup resistor of 1.5K, and shows no really measurable difference between boards that work and boards that don't.

I am a little peeved at Mitac, though.

If you're going to put a pullup on an I2C line, I would put on a high value. The peripheral can always put another one in parallel to lower it. If you start with a low value, there isn't much that can be done to change it. Most common I2C pullup values are quite a bit bigger than 1.5K. Putting any of them in parallel with 1.5K can only make a slight difference....for instance:

10K in parallel....gives 1.3K total
5K in parallel....gives 1K total

yada yada yada...

And there's no way to easily make it bigger.

 

Plan B is using an SMBus port on another connector of the motherboard. It already runs at 3.3V, so we don't need a level shifter.

We've also found that the Integrated level shifter that we're using doesn't always play nicely with I2C lines. I'll have to make a sketch to show what the issue is...but...under some circumstances, it actually shorts the high rail to the logic level to bypass it's own internal pullups. The data sheet calls this an "accelerator", as in, it squares up the rise times of the signals....but some devices on an I2C line may not like it..

 

They expect to have some length of cable, so it's only natural to use stronger pull-ups. I'm not sure, but I would expect the size of pull-ups mentioned in the HDMI specs.

From what you describe, it rather appears to be some sort of problem with either their firmware or yours. Since they have tested and released it, it's most likely yours.

 

They expect to have some length of cable, so it's only natural to use stronger pull-ups. I'm not sure, but I would expect the size of pull-ups mentioned in the HDMI specs.

From what you describe, it rather appears to be some sort of problem with either their firmware or yours. Since they have tested and released it, it's most likely yours.

Firmware isn't even involved yet. We're simply doing a script program to persistently poll the HDMI I2C and tell us what addresses are identified.

I understand that cabling would be assumed, but going all of the way down to 1.5K right off of the bat leaves little wiggle room. Most I2C runs happily at 4.7K, 10K or higher, even over distances that would go from one end of a tower chassis to the other.

The second part of that is that it's fine to have the low resistance, as long as you have a driver that can pull that resistance down. We measured the I2C signals right at the motherboard output, and the "logic low" level is never lower than 0.6V.

Add in some cabling, and you have logic low levels of sometimes 0.9V at our display driver board.

I attached some LTSpice (free from Linear Tech) simulations.

It seems that the only hope would be a discrete level shifter that would allow me to adjust the pullups on each side independently. It seems to work best with very high (39K or so) on the 5V side and very low (1K or so) on the 3.3V side.

Real world experiments validated the first part, as in I get reliable 5V I2C with high pullups on the 5V side, but I can't seem to find a value on the 3.3V side to work with it.

I'm about ready to punt here and look at communicating with the touch screen via some other port. Maybe USB to I2C....