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.

ISO1641: SCL not consistently passing from side 1 to side 2

Part Number: ISO1641


Tool/software:

Hello,

We are using the ISO1641 in an I2C level translation application with Side 1 at 3.3 V and side 2 at 5V. We do not need the isolation feature, so the grounds on both sides of the device are tied to our common ground net. We have SDA and SCL pull ups on both sides of the device at 2.43 kOhms each. We are observing that in a 6 byte transaction across the level translator, that occasionally clock pulses on side 1 are not being mirrored on side 2, instead side 2 is just held low for the clock pulse. We're not going fast, this is at 100 kHz. When the clock signals are passing through, they look quite clean on the oscilloscope on both sides of the isolator/level translator. On the primary side, we have 2 other I2C devices connected to the bus (3 if you include the master). I wouldn't expect this to violate the capacitance limitations, and if it did I'm surprised that we'd so consistently have the same clock pulses not getting through. I'm wondering if you have any recommendations for what to try to resolve this issue?

In the scope traces below, the yellow trace is the side one CLK signal at 3.3 V, and the green trace is the 5V secondary side clock. You can see that some of the yellow clock pulses are not making it from side 1 to side 2, and sometimes part way through the primary side clock signal the secondary side suddenly rises up and starts tracking the primary side again. 

Thanks,

Neal

  • Adding that there's an existing forum post stating that the application with shorting the grounds from the two sides shouldn't prevent the device family from operating properly as a buffer/level translator. 


    Also, wanted to include schematic snippet of the part. Note that the Side 1 pull ups are on a different sheet, but they exist.

  • Hi Neal,

    Thanks for reaching out and for the detailed inputs. Please find my comments below:

    1. Looking at the higher rise time from the scope shots, it does look like it can be capacitance issue on Side1
      1. For debugging this angle, please disconnect the other two devices on the Side1, leaving only master connected on Side1 and then check for the same sequence from Side1 to Side2.
      2. You can also check the Bus Capacitance with all the 3 devices installed and make sure the value is <80pF.
      3. Not really sure right now, why the same clock pulse is getting missed consistently. Let us know on the above to root cause this further.
    2. The VOL1(Max) of ISO1641 is 0.71V. Make sure the logic compatibility between master and Side1 is taken care of. VIL(min) of master should be >0.71V for the signal
      1. The above comment is more valid for transmission from Side2 to Side1, but make sure the logic compatibility is taken care overall.
    3. On a general note, for the optimal operation of ISO164x, it is always recommended to have only single node on Side1 as already mentioned in section 9.2.2. So please do check the transmission with just single node master connected on Side1.

    Looking forward for your feedback.

    Regards
    Varun

  • Hello Varun,

    Thank you for the reply and follow up questions. In trying to gather the requested data, I noticed that the problem goes away when one of the devices on the secondary side of the level translator buffer is disconnected from the bus. I put a small series resistor in line between the level translator buffer IC and the suspect device and found that when the SCL net is being unexpectedly pulled low the voltage across the series resistance indicates that the level translator buffer IC is not what's holding the net low. So I have reached out to the manufacturer of the suspect device for further support. I do not believe there is an issue to be resolved with the ISO164x IC, and apologize for heading down that path without fully understanding the source of the problem. Thanks again for the support you provided.

    Thanks,

    Neal