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.

ISO1541-Q1: Can't find all I2C addresses

Part Number: ISO1541-Q1
Other Parts Discussed in Thread: ISO1541, ISO1540

Hi team,

My customer need assistance.

I’m using ISO1541QDRQ1 as I2C isolator on a custom board. I’m testing the board and I have a problem finding the I2C addresses. On side 1 I have the master, and on side 2 I have 4 slaves. When I do a I2C scan on side 1, I can only find 1 of the 4 I2C slaves, but if I do the I2C scan on side 2, I can find all the slaves, so the problem seems to be the isolator, because before it the I2C bus Works perfectly and I can communicate with all of the devices.

Please help. Thanks.

  • Hi Chong,

    Thanks for reaching out.

    The device ISO1541 is a physical layer device which transfers I2C signals across the isolation barrier without any data processing. Hence, the first step to debug the issue is to check if the connected I2C nodes are compatible to the logic thresholds of ISO1541. If they are all compatible, then you would have to monitor the input and output waveform to check if the device is transferring the data across correctly.

    To better understand the connection of nodes, could you please confirm what nodes are connected on which side? If you would like me to verify if their I/O levels are compatible, please share the larger schematic showing all nodes and their part numbers.
    The schematic doesn't show pull-up resistors on Side1, I am assuming they are just not shown in this snippet but they exist.

    Please help me with above information to help debug the issue further, thanks.


    Regards,
    Koteshwar Rao

  • Hi Rao,

    I got the reply from customer:
    Yes, the pull ups not shown on side1 but they exist.
    The slaves devices are:
    PCA9554BPWJ
    MCP3427
    MCP3426A0T
    SC18IS606PWJ
    I can only find the last one, SC18IS606PWJ.
    The 4 slaves devices have the +3V3_ISO power supply and GND_ISO as ground.

  • Hi Chong,

    Thanks for sharing the part numbers of 4 devices connected to Side2 of ISO1541. Can you please also share the part number of the device that is on Side1?


    Regards,
    Koteshwar Rao

  • Hi Rao,

    We are using an Arduino Mega to test the I2C bus, so that’s the device that is connected right now on side 1. On the final application, we will have a CC1352 (power supply 3v3). If you need photos of oscilloscope waveforms I can send you.

    Thanks.

  • Hi Chong,

    Thanks for sharing the part numbers for the 4 devices on Side2. I looked at their datasheets and their I/O thresholds are compatible with Side2 of ISO1541.

    Regarding the Arduino Mega board, I see that the board uses ATmega2560. I looked through the datasheet of ATmega2560 and I couldn't find the I/O thresholds or specifications for the SDA and SCL pins. Could you please ask customer to share the VIH, VIL and VOH specifications of SDA and SCL pins of ATmega2560?

    If you need photos of oscilloscope waveforms I can send you.

    Yes, scope waveform showing Side1 and Side2 mismatch captured in the same waveform would help us determine if the device is causing any issues. Thanks.


    Regards,
    Koteshwar Rao

  • Hi Rao,

    I got the reply from customer.

    Hi,

    I have been testing the I2C isolator using an Arduino and a Raspberry Pi3 too.

    The next photos are oscilloscope waveforms using the Arduino.

    Side 1:

    SCL

    SDA

    On side 2, where the slaves are connected:

    SCL

    SDA

    The next photo is the result of doing an I2C scan with the Arduino. As you can see, I can only find one of the three addresses that should appear (on this board one of the slaves is not mounted, so there should be three addresses, not four as I said on other posts)

     

    On other hand, using the Raspberry, I cannot find any address, even the 2F that I find using Arduino. This address belongs to SC18IS602BIPW,128. The next photos are the waveforms of I2C doing an I2C detect from Raspberry.

    SCL on side 1:

    SDA on side 1:

    SCL on side 2 (slaves side):

    SDA on side 2:

    Finally, I tested the I2C isolator connecting the Raspberry wires directly on the side 2 pins finding all of the addresses as you can see:

    The next photos are the waveforms from this last i2c detect (when all addresses were found)

    SCL

     SDA

    Thanks a lot for your help.

  • Hi Chong,

    Thanks for sharing all the waveform related to SCL and SDA pins of ISO1541. Please see my inputs below

    1. Like I mentioned earlier, ISO1541 is a simple buffer with isolation integrated. It's function is to simply pass data from one side to another. The only way we can confirm whether the device is doing its job correctly is to look at SCL1 and SCL2 waveform in a single capture. i.e., one waveform plot showing both SCL1 (on CH1) and SCL2 (on CH2). This will enable us to compare if the input and output data is matching or not matching.

    Similarly, waveform for SDA1 and SDA2 captured in a single waveform capture to enable us compare them in the same plot. Please share these waveform to enable us to debug the issue.

    2. If the waveform look good and if ISO1541 is working fine then the possible issue could be that the software hasn't accounted for the propagation delay caused by the addition of ISO1541 into the system and probably that's why they see it working without ISO1541 and doesn't work when ISO1541 is added to the system.

    3. One other possibility, I can think of, for the issue to occur is clock stretching. Do you know if the nodes on Side2 use clock stretching to notify the node on Side1 to wait? If yes, then ISO1541 will not be able to clock stretched feedback to the Side1 as ISO1541 has a unidirectional clock. If customer suspects this issue, then I would recommend them to try testing ISO1540 which has both SCL and SDA as bidirectional channels.

    Please do share above information with customer and help us with the requested data, thanks.


    Regards,
    Koteshwar Rao