This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ISO1640: ISO1640 Stability Issue due to Vol

Part Number: ISO1640
Other Parts Discussed in Thread: INA237, , INA232, TCA9517A, TCA9803, P82B715, TCA9517

Tool/software:

Hi TI Team,

We are experiencing I2C stability issues between ISO1640 and our I2C Master CPU especially at higher operating temperature.  This is due to the output low voltage of ISO1640 and input low voltage of our CPU.  We can't switch to side 2 of ISO1640 because we will have the same problem with the INA237, INA232 and another slave that has Vol as high as 0.8V currently on the other side of the isolator.  Would placing TCA980x side A to cpu and side B to ISO1640 work? Or if you have any suggestion please let me know.  This is quite urgent, please answer as soon as you can. Thank you. 

  • Hi Khoa,

    Thank You for reaching out. Please find my inputs below:

    nother slave that has Vol as high as 0.8V currently on the other side of the isolato

    Are you suggesting that between side1 of 1640 and CPU, you have another slave? If yes then please make sure that there is no overlapping including min max numbers across temp between ISO1640 VIL1 and Slave's VOL.


    Would placing TCA980x side A to cpu and side B to ISO1640 work?

    On the use of TCA980x for voltage translation, it should work fine as long as VILB of TCA980x is higher than VOL1 of 1640 and VOLA of TCA980x is lower than VIL of CPU .

    Regards
    Varun
  • The B side of the TCA980x must not be connected to an output with a voltage offset (or to an I²C switch), and side 1 of the ISO1640 does have a voltage offset.

    To improve the VOL on the ISO1640's side 1, you have to connect the TCA980'x A side to it, and the B side to the MCU (and remove the pull-ups on the MCU side). Alternatively, switch the sides 1/2 of the ISO1640, and put the TC980x on the other side, with the B port towards the INA2xx devices.

  • Hi Varun,

    Thank you for your quick response.  

    No the 0.8V VOL slave is on side 2 of ISO1640 (side 2 VIL = 0.99V) so this is not a problem.  But because of this high VOL slave, I can't flip ISO1640 sides to make it compatible with the CPU.

  • Thank you Clemens.  Unfortunately the CPU I was referring to is a module that came with the pull-up installed and there is no way we can remove the pull-up from it.

    Flipping ISO1640 and add TCA980x on the other side is a good idea.  Will try that out.  Thank you for your help.

    Khoa

  • Hi Khoa,

    Understood. Thanks for letting me know the details.

    As Clemens suggested, you can try to switch the position on TCA980x and ISO1640(and flip it). 

    Regards
    Varun
  • I tried what Clemens suggested today and the result is better but we still have errors. Occasionally we have "I2C arbitration Lost" and they system went nut when this happened.    

  • Hi Khoa,

    Thank you for considering Clemens inputs, testing and confirming the results. Not sure why this isn't resolving the issue completely and maybe there is another issue with the schematic or PCB layout.

    Could you please try using TCA9517A instead of TCA980x and check if this is compatible?
    TCA9517A allows use of pull-up resistors, therefore, this can be connected to MCU without any concerns.
    Please make sure SideB of TCA9517A is not connected to Side1 of ISO1640. Thanks.


    Regards,
    Koteshwar Rao

  • Hi Koteshwar,

    TCA9517A was the first buffer I tried before I considered the TCA9803, but both didn't work.  One thing I failed to mentioned was that the ISO1640 and INA237 (4x)  were on a separate board, connected through a 1 foot cable from the main board where our CPU is located. Could this be the reason why TCA9803 didn't work?

    I checked TI website today and saw I2C cable extender, Part Number P82B715.  Could you guys tell me if the Sx/Sy side can work with side 1 of ISO1640?

  • Yes, a cable might affect I²C communication. And if you need isolation because of noise, then this is where the I²C signals are likely to get corrupted.

    Please check with an oscilloscope at which place in the chain the I²C signals are OK, and where they aren't.

  • Hi Khoa,

    Thank you for providing further update. Sorry that your problem is still not resolved.

    Like Clemens mentioned, yes, the cable could affect the logic levels and the actual signal observed at the pins. To verify this, you could test the boards two avoid the 1 foot cable and connecting them together using a much small cable.

    I am not sure if a cable extender would help and I also don't see their logic thresholds listed in datasheet. Please help test your boards using shorter wires and using both TCA9803A and TCA917A and let us know the results, thanks.


    Regards,
    Koteshwar Rao

  • Hi Koteshwar,

    TCA9517 was the first buffer we tested before we moved to TCA9803 and both had errors. The cable can be made an inch shorter as most due to physical constraints. We may need to drop I2C and go with differential if we can't find a work around quick enough.

  • Hi Khoa,

    To understand if the long cable is the actual root cause of this issue, can you please try to probe the signals after the 1foot long cable and check for signal levels if they are still at same expected level or for any noise interference due to some other source in the system.

    Please let us know if you find something unusual there.

    Regards
    Varun