DIX4192: I2C read access issue

Hi Hans,

Would  you please  send me the full script that you send to the device ,  including your read request and I will take a look at it.

Thanks,

Arash

Hi Arash,

I program the device with a microcontroller on a custom board - so there is no script to explain the access. But I have recorded the I2C traces for both cases. This is what happens:

0. The device receives a hardware reset (not shown)

1. Write 0x3E to register at address 0x01

2. Read register at address 0x01 
    Case a) with a STOP condition at the end of the address phase and a new START condition for the data phase
    Case b) with a Repeated START condition between address and data read phase

Case b) fails as the read back value is 0 and at the same time the device seems to undergo a reset (all other registers read back 0 and all ports are disabled). Case a) works fine. Interestingly, case b) works fine with all other register addresses, but address 0x01.

In my understanding, case a) and b) are equivalent to the described "Read Operations" in datasheet fig 22 a) and b), respectively.

Regards,

  Hans

Hi Hans, This is an interesting problem! Can you please read few other registers and see if the value of those would change they way this register changes?

Also is there a way to change  the timing for this WAIT period

Let us know what you find and we can go from there. 

Regards,

Arash

Hi Arash,

sure, here are three traces for direct comparison: The first is the register 0x01 read with standard wait time, the second is the same access with the wait time increased from ~25us to ~113us - which still fails, and the third is a read access to register 0x07 which succeeds (other register reads succeed as well). I suspect that the I2C state machine generates a glitch in the addressed register which, in case of address 0x01, triggers an asynchronous reset of the chip. It would be interesting to check a GPIO pin configured as active high (or low) output if such a glitch could be observed directly when reading from GPO control register with repeated start condition. However, my custom board is lacking the accessibility to these pins.

Regards,

  Hans

Hi Hans, thanks for doing the  tests and confirmed this happens only in this register when repeated read is inserted. I tend to agree with you that it seems it is a glitch in state machine on this  specific register. I think the only remedy is to have a full stop and then read following that, nevertheless  I will  consult with other engineers and let you know by Thursday.

Regards,

Arash

Hi Arash, here is another test I was able to run after attaching a probe to the GPO1 pin. First, GPO1 control register 0x1b is set to 0x01 to force GPO1 high. The register reads back successfully with a repeated start condition. Then, I read back register 0x01 with a repeated start condition and GPO1 switches low (its default state) with the final rising SCL edge at the end of the address phase. That seems to be the moment when the configuration registers are wrongly reset. I also checked the setup- and hold timing for the (repeated-) start condition and they they are within the specs. Also switching to I2C fast mode does not change the observed behavior.

Regards,

  Hans

Thanks Hans, I will review these with my colleagues and get back to you on Thursday.

Regards,

Arash

Hi Hans, How RST pin is connected ? Can you monitor the RST pin behavior. We are wondering if this pin is triggering the reset condition.

All the I2C waveforms are within the protocol 

Regards,

Arash

Hi Arash, the RST pin is driven from a microcontroller output in push-pull configuration and I don't see any spurious signals on this line. If there were, the reset should occur also occur reading other addresses, I guess.

Regards

  Hans

Hi Hans, there are only 2 mechanisms to trigger the reset. One is the external RST pin and the other one is the internal to the device. Since you monitored the pin and there s no spurious signal on it, the only one left is what we were suspected from the beginning which is the spike in repeated read on register 01.

I don't have access to design base to review or simulate it and see if I can find anything that explains why it does this to this register. I  think the only option is to work around it and if possible do the read but not repeated start . 

Regards,

Arash