DS90UB925Q-Q1: I2C interface output clks randomly

Since we need isolation in our system we take the (1st)925 data output and i2c signals and run those through a digital isolators. From the (2nd) 926 point of view it just sees the I2C input from the isolator as the master I2C interface. So I would think unless I see data on the I2C pins of the (2nd)926 I shouldn't see any data coming out of the (2nd)925. There are no I2C master devices on the (2nd)925 side that could cause these clocks pulses to happen.

I will try to capture with a scope but it will be hard since this issue happens will trying to read 128 bytes of data and it doesn't always happen at the same time. I need to figure out a way to get the scope to trigger on this event.   I have 1.6k pull ups on the scl signal so it has fast rise times and I'm running the scl at 64khz.

Yes the isolator I'm using is si8600ad it is bidirectional.

Some more info is things work it only fails when I start to send or get lots of data back to back in a short period of time. 

I could not find a listing for  bandwidth but it can support clock speeds up to 1.7Mhz.

The control is built in there is no pin to toggle to set direction.

Here is the full part number Si8600AD-B-IS. I'm setting up to get captures of data on both sides of the part. I will then short it out for now just to see if the issue goes away.

While doing more set up and debug I noticed that the extra clock pulses only happen after the first read command is set. 

The order is write to 0x54 send 5 set up bytes followed by 128 dummy bytes that tell the I2c bridge how many bytes to read.

Then I send a 0x55 read command and at this point I see the extra clock then I read the bytes that come from the I2C bridge.

This happens after every read command is sent. In the image I attached before the values are shown in Decimal.

Sorry for all the messages but I thought I would give updates as I come across them so I don't forget while working on other things.

New update is the clock issue I reported seems to be proper operation. The 926 or 925 not sure which seems to switch to a I2C master mode and when it sees the read command it outputs extra clocks to get data from the slace device so during the next read request the 926 will have the data to send back to my main master device. So that answers the clock question. But looking at it further I see during the read the main micro send a ack to the 926 after it gets a byte but for some reason not sure which device either the 926 doesn't send the ack to the 925 or the 925 gets it but is busy and never puts it out to the slave I2C device. I enclosed this pic that shows toward the end of this lock up. This shows after ~.257 sec the 926 seems to release the scl pin and then the master micro starts to send clocks to get more data. At this point the 926 seems to respond with 0xff for each request then once the master micro sends the nack to stop the read process the 926 goes back to normal operation and everything is good. Looking at register 0x04 in the 926 I see a BCC watch dog and the value there seems to be the same as my time out. So the question now is what could cause the 926 or 925 to get to this delay or lock up state? How do I check the quality of the channel link? I will run a test tomorrow to see if I disable the BCC watch dog does this happen or will it evenly send the ack out fro the 925.