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.

ISO1540-Q1: Acknowledge level issue on interface with TCA9511A

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

Hi,

On our test setup, we have the following summarized schematic:

It doesn't show the routing length or the different connectors, basically the board (left part) is plugged onto the test tray (right part) and on the test tray the two sides are connected through routed wires and through a set of 2 connectors with an he10-like cable assembly (the two parts can be interlinked or not depending on our tests needs).

We have that schematic twice as our tested board has two channels.

On the first channel, it worked like a charm, however on our second one it does not as you can see from the following screenshots (don't pay attention to the label we forgot to remove them) which are taken in between the TCA9511A and the ISO1540:

When zooming, it seems the acknowledge tries to goes high but can't:

If we let the oscilloscope continue, we see spurious event where the signal tries to go high (maybe to send the acknowledge):

Note that in the above screenshots, we changed the 10k pull-ups on the ISO1540 to 1k as we thought that could be the problem as we were having high resistor values compared to the datasheet.

It only changed the level of the spikes from about 1V to about 2V (it would have been odd if it fixed the issue as we see the problem on the other side of the isolator).

I read on another post that the ISO1540 was using SVo and that it wasn't compatible with another TCAxxxxx device but the TCA9511A datasheet doesn't speak about SVo, and moreover I don't see why it works for one channel and not the other considering I checked the schematic and I see no issue nor any discprencies.

Best regards,

Clément

  • Hi Clément,


    Thanks for the detailed description of the issue. 

    The value of pull ups will change the rise and fall time which affects the data rate, but it will not have any effect on the final voltage. The 1V and 2V spike difference is for the same reason. To calculate the pull up resistor value, please refer to I2C Bus Pull-Up Resistor Calculation

    If you have two channels on the board and first channel worked without an issue. We believe there is a connection issue on the second channel. If there is no discrepancies between two channels in schematic, then please share the SDA1 and SDA2 sides snapshots of both channels to understand if the communication is successful and ACK signal is generated on SDA2.

    Please give us another day to verify if TCA9511A is compatible with 0.8V VIL  requirement as mentioned in our (+) [FAQ] Why is the logic LOW level output voltage, VOL1, up to 0.8V on Side1 of the ISO1540/ISO1541 and ISO1640/ISO1641 bidirectional I2C isolators? - Isolation forum - Isolation - TI E2E support forums

    Thanks

    Vikas J

  • Hi Vikas,

    We have checked thoroughly our design and yes both channels schematics are identical.

    I have taken snapshots of the signals as requested.

    For the working channel:

    For the failing channel:

    I have attached two snapshots because we saw that sometimes the I2C address byte is acknowledged properly but not the data byte (first snapshot) and sometimes not (second snapshot).

    What we see on both is that the SDA does not go back to high state once it fails, we need to reset/restart both TMS320F28386D CPU for the signal to go back to the high state (idle).

    On the failing channel, the observed level on the ACK bit differs a little from the working channel, it seems and it looks like the ISO1540 stays in the SDA2 => SDA1 direction after the last ACK bit.

    Best regards,

    Clément

  • Hi Clément,

    Thanks for the captures. In pass or fail condition, I am seeing that SDA1 and SDA2 states are equivalent. The device is not going back HIGH on SDA2 and hence it is failing. 

    Could you please swap the devices and test it again on the failed channel to understand if there is any external factor pulling the SDA2 line 
    to low state. To me, the SDA1 and SDA2 lines of ISO1540 are behaving as expected. SDA1 is around 0.8V, so that is not being pulled low. We need to figure out what is causing the SDA2 pulled low, swapping the devices and testing will help us narrow down the issue.

    Thanks

    Vikas J

  • Hi Vikas,

    Thanks for the captures. In pass or fail condition, I am seeing that SDA1 and SDA2 states are equivalent. The device is not going back HIGH on SDA2 and hence it is failing. 

    You mean it's not going back on SDA2 for the failing channel ? Yeah. However it goes back high for the working one.

    Could you please swap the devices and test it again on the failed channel to understand if there is any external factor pulling the SDA2 line to low state. To me, the SDA1 and SDA2 lines of ISO1540 are behaving as expected. SDA1 is around 0.8V, so that is not being pulled low. We need to figure out what is causing the SDA2 pulled low, swapping the devices and testing will help us narrow down the issue.

    Hum... We don't have the in-house material to do so, I'll have to see.

    I can also maybe try to communicate a setup where I only have the ISO1540 or the TCA9511A, after all the problem could be related to what you highlighted in your first post or these screenshots says otherwise ?

    Clément

  • In fact, we have a mean to invert the signal in order to redirect differently the two buses.

    The setup will be a little different as we will need to go through 2mm socket wires but that would be a first step towards what you suggest to test.

    Clément

  • Hi Clément,

    Clément said:

    You mean it's not going back on SDA2 for the failing channel ? Yeah. However it goes back high for the working one.

    I meant that SDA2 on the failed channel is driven by the device on the right side instead of waiting and reading SDA2. This can be deduced from SDA1 = 0.8V. Whenever SDA2 is driving low, SDA1 will be 0.8V. 

    The ways to narrow down to the actual problems are

    1. Swap the devices and test again. 
    2. swap side1 and side 2 connections, i.e connect side2 to TCA9511A and side1 to the device on the right.

    Side 1 is ideally to connect to the MCU on the board but in your setup, there are wires connected to side 1 and TCA. That might be little sensitive. If you swap the sides, it should eliminate any such dependencies as well. 

    We are seeing that ISO1540-Q1 is behaving as expected and the external factors like wires or the device on the right are driving this to failure.

    Thanks
    Vikas J

  • Hi Vikas,

    I meant that SDA2 on the failed channel is driven by the device on the right side instead of waiting and reading SDA2. This can be deduced from SDA1 = 0.8V. Whenever SDA2 is driving low, SDA1 will be 0.8V. 

    That would mean the MCU on the right (called Test Tray) is driving low SDA for more than one bit.
    This device is a TMS320F28386D, what would make the I2C peripheral from that MCU behave so ?

    Note also that, I did not state it earlier, we only have a single MCU on the right (test tray) interconnected to two identical channels.

    Swap the devices and test again. 

    So this morning we have used a cable breaking-box to invert the interconnected channels one with the other.

    In that setup, both channels are failing, the MCU on the right does not receive any data from one or the other channel.

    We have used 2mm patch cords of about 50-75cm for the interconnection.

    swap side1 and side 2 connections, i.e connect side2 to TCA9511A and side1 to the device on the right.

    The components being mounted on a board, it's not that easy to do that.

    Side 1 is ideally to connect to the MCU on the board but in your setup, there are wires connected to side 1 and TCA. That might be little sensitive. If you swap the sides, it should eliminate any such dependencies as well. 

    Can you explain us why the side 1 and TCA being connected together from ISO1540 side 1 is sensitive ?

    That "sensitivity" would explain why the TMS320F28386D keeps a 0 on SDA longer than 1 acknowledge bit ?

    Clément

  • Hi Clément,

    The reasons why we are suggesting you swap the sides is that on side 1,

    1. VOL of ISO1540-Q1 is very close to VIL of TCA9511A and the cables might cause it to go into indeterminate state.
    2. Side1 connected to MCU will show 0V which clarify that MCU is driving the SDA2 low and ISO1540-Q1 is not the issue.

    To investigate it further, please provide the complete schematic and the test tray connections. The explanation on the test setup is a bit confusing.

    Thanks
    Vikas J

  • Vikas,

    I'll draw something tomorrow to help you understand the initial test setup and the test setup I used today to invert the two channels.

    Clément

  • Hello Vikas,

    I have drawn our full setup including the connectors etc...

    Everything is routed through PCB tracks, except at one point where there is a ribbon but I drew it so you have the info.

    That ribbon cable is 15cm long.

    In that setup CH1 works, CH2 does not work.

    The version where we tested the channels inversion is below, we inverted thanks to 2mm banana socket and made the connection with 2mm banana wires of 50-75cm.

    Best regards,

    Clément

  • Hi Clément,

    Thanks for the detailed schematic.

    What was the result after the channel inversion?
    CH1 still works and CH2 doesn't?

    Thanks
    Vikas J

  • Hi Vikas,

    In the inverted configuration none of them work.

    Clément

  • Hi Clément,

    Thanks for the confirmation. The schematic looks fine. 


    As we can see that, using cables to invert the channels results in both channels not working. 
    As mentioned earlier, swapping the sides 1 and 2 is the best way to narrow down the issue. "
    VOL of ISO1540-Q1 is very close to VIL of TCA9511A and the cables might cause it to go into indeterminate state."

    Please test after swapping the sides. One way to do it would be to solder the device upside down. Although it is a little tricky but it would work.

    Thanks

    Vikas J

  • Hi Vikas,

    Yeah that's what I was thinking, I'll have to see how we can have that done.

    It will take a little time though.

    Thanks,

    Clément

  • Hi Clément,

    I am closing this thread due to inactivity. Please feel free to create a new post once you have tested with sides swapped and results are available.

    Thanks

    Vikas J

  • Sure, no problem, it will take about a month before I can test out.