I2C Guru?

[KL27x]

I am trying to commandeer and read data from a parallel to I2C (SMBus?) IC. It has in-house identification on it. But the pinout appears to be same as a TCA9439.

I have never used I2C, so I verified my PIC code with a 24LC512 EEPROM, and I can read and write from this EEPROM, no problem.

I have scoped the device in question, while it is being read, and the 7 bit device address is read as 0x42/0x43 (the last bit being the R/W bit). 

So the problem is, when I put my own micro on the SCL/SDA and do send a start bit followed by this address, R/W bit 0, it ACKs me back. Then I follow that with the start address to which I want to read (as snooped by scope/LA). It ACKs. Then I send restart bit. Resend device address with R/W bit set (43h). This all matches with what I am snooping, and it concurs with I2C protocol as I understand it, and it works when reading from an EEPROM IC. And...

This chips sends out data. But this data does not match the data I am scoping when the original circuit's Master does a Master Read from the chip. (And changing the physical state of the I/o pins on this extender does not change the garbage data I am reading.)

Also when looking at the physical chip, the pinout appears to be indentical to TCA9539. As opposed to PCF8575, because it appears a Reset pin is wired up rather than A2. Except the way the address pins are set, the address of this device should be 0x46/0x47. A1 and A0 address pins are both tied to Vcc. This is the only I2C slave I can find on the bus (I admit I have not yet tried reading from address 0x46, so I will have to update. But the data that the original circuit is reading IS definitely the ports on this chip!)

I have matched the clock speed within 1%. The only difference I can detect between the way the original master polls this device and the way mine does, is the MSSP I2C hardware I am using seems to take longer to verify the ACKs. I mean, when my code is doing it, the clock pauses at the ACKs. The original circuit ticks the SCL like clockwork.

I don't really expect anyone to be able to diagnose this thing from my so far terrible debugging. But hey, just in case. I'll try updating with additional info and screenshots of the LA output and anything else I can find out.
 
Summation so far:
My own eyes on a scope are reading address as 0100001x. LA is reading address as same. But physical circuit shows 0100011x if going by TCA9539/PCF8575 datasheet. Chip is returning nonsense data when I try to Master Read it. Anyone ever run into a protected I2C/SMBus device before? Anyone familiar with 16 bit I2C I/O expanders other than the aforementioned devices? These are the only 16 bit IO expanders my google-fu/mouser searches can dig up.

*Edit: tried addressing device 0x46, and no response. It is definitely responding to 0x42 from the original master and my own. It is just not sending the right info to my own Master Read request. I have tried with the original master disconnected from the SCL/SDA lines. I am a surprised at how similar this device and circuit look to a TCA9539 with pins/circuit setting address to 46h, though. It is uncanny.   
 
**update: while the original Master is still connected, I can Master Read from the chip the correct information! So I guess I'll look closer at signal integrity and the exact structure of the I2C circuitry (as if there is much) on the original circuit for one. And two, look closer to see if there isn't some master to slave information stream that is affecting the expander IC when I disconnect the original master.  On my own circuit I just have a 4.2K pullup on each line. But... the addressing and ACKing is all kosher and it looks ok on the scope... so I don't think it's the hardware.

**update: Every second, the master is reading 3x 2 byte strings from the slave device from start locations other than 0h... which on a port extender, I don't think these alternate addresses would exist? This one might be special? I'll have to dig a little deeper.

***one of these addresses is a control register (on a TCA9539, anyway). Two don't exist, AFAIK. So at start up, the Master is writing to two control registers. And two mystery registers. Then every second or so, it is reading the contents of one control register and two mystery registers... which so far, unsurprisingly, returns the same information that was written at startup. I wonder if these reads are part of some sort of watch dog setup?

[CJay]

TCA9539 uses slave address 0x74-0x77 so if it is one of those it's unlikely to respond to 0x46 address if it is that part.

Try it with the datasheet addresses?

[Maxlor]

Maybe it's really a PCAL6416A or TCA9555. Both of those can be configured to the addresses you mentioned. Note that the PCAL6416A appears to be backwards-compatible to the TCA9555, but has a lot more functionality (read: registers) built in. Maybe what you see makes more sense if you assume your mystery chip is one of those?

[donmr]

When in the original circuit, are you sure that this is the only device connected to the I2C signals?
An I2C bus can be shared with many devices, your scope could be seeing signals to/from a different one.

[KL27x]

TCA9539 uses slave address 0x74-0x77 so if it is one of those it's unlikely to respond to 0x46 address if it is that part.

Ahh, yes. Oops. In hindsight, I had the addressing of the PCF8575 in mind but looking at the pinout of the TCA9539. Because of the pin which would be "A2" on PCF appears to be wired to a RESET circuit.

When in the original circuit, are you sure that this is the only device connected to the I2C signals?
An I2C bus can be shared with many devices, your scope could be seeing signals to/from a different one.

Thx, that is a good point. I would not know for sure. The board is only 2 sided, but I cannot trace the entire SDA SCL due to obstructions. But > 1 seconds worth of LA show only read/writes to address 42/3h. And this is the only device I am interested in...(I'm sure it's the correct device from physical manipulation of the ports while using scope!)

Maybe it's really a PCAL6416A or TCA9555. Both of those can be configured to the addresses you mentioned.

...PCAL6416A... has a lot more functionality (read: registers) built in. Maybe what you see makes more sense if you assume your mystery chip is one of those?

Winner, winner @Maxlor. I believe you nailed it. My computer is not able to pull up the TCA9555, right now. But the PCAL6416A fits like a glove.

"A2" is a RESET pin? Check. "A1" is actually Vdd for the I2C bus, explaining why it is tied to Vdd, but address is still 42h (0 in the A1 bit) rather than 46h (1 in the A1 bit)? Check. And the "mystery register" addresses (46h and 48h, which if I had posted this info earlier, I bet u would have known for sure!) not only exist on this device, they make sense in the context. These two registers control the pullups on either port, and if misconfigured could explain the nonsense data I was reading, at first. Big thanks. This is very helpful. 

*Not only does Mouser carry this but it is significantly cheaper than the lower-functionality parts I ordered!