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.

SN74CBTLV3384: Can the switch somehow cause errors, like pulling the line low when using IIC?

Part Number: SN74CBTLV3384

Hello!

I've got a prototype design using an SN74CBTLV3384 bus switch, used to protect the input pins of a modem IC.

The modem does not have a traditional RESET input, and reset is only possible by cutting it's power source. During that, the pins of the modem should be protected. The modem communicates at 2V8, and the manufacturer recommends using level shifters with high impedance mode to connect the IC to a 3V3 system, and protect it's pins during these "resets". To reduce the possibility of error and remove the need to use level shifting, I designed the whole system to use 2V8, and added the above switch to protect the input pins of the modem when it is not powered (not only during reset, but to reduce power consumption too, when the modem is not needed). So, the VCC, the control signals, and the signals routed by the switch are all 2V8.

Anyways, I've got SPI, UART, IIC and some GPIO pins routed through the bus switch, all running perfectly fine, even at high speeds (UART at 460800 baud, SPI at 10MHz), except for the IIC (40kHz). I regularly get errors, about 50ppm transfers are ruined. Of course, nor the modem, nor the MCU on the other end of the channel use the exact IIC protocol, so the problems could be caused by software, or peripheral errors. After looking at some oscilloscope measurements the manufacturer of the modem suggested that the switch may cause the problem. (Sometimes strange voltage levels appear on the line at about 1.4V, but my bet is on the modem using push-pull to control the IIC line, instead of open-drain.)


So, my question is :
- Is the above design to protect the pins of the modem viable?
- Can the switch somehow cause errors, like pulling the line low when using IIC?
- If so, can you suggest some more robust design? (The cost of the solution is very important.)

Thanks for your help in advance!

  • Thomas,

    Many customers use signal switches and multiplexers, especially ones like SN74CBTLV3384 with powered off protection feature, to help isolate sections of their system.  I haven't seen anything in your description so far that leads me to believe that using the signal switch in your system is not a viable solution.   

    The SN74CBTLV3384 device is a passive FET switch and can ideally be modeled as a 0 ohm wire.  Since it is a passive FET switch it does not have the ability to pull a signal path low it will simply pass a signal from one side of the FET to the other.   You can find more information about these types of switches in the app note " Selecting the right Texas Instruments signal switch"

    1) It is good news that you have other protocols running through your system without issue.  One way to help you narrow down if the issue is the switch or something else in the system is removing the switch and shorting the signal path to see if the issue still is present. 

    2) Would you be able to provide the scope shots that lead you to believe the switch is distorting the signal?  It would be good if we can see the A pin and B pin signal to see if there is any distorting through the switch.

    3) Do you have a section of the schematic we can review?  It can be useful in I2C open drain applications to place pull up resistors on both sides of the switch to help reduce errors and define the bus state when the switch is transitioning from conducting to Hi-Z.  However it sounds like this is not the case in your application. 

    Thank you,

    Adam

  • Dear Adam,

    Thanks for your reply.

    I read a lot of TI materials before choosing the switch, including the ones you mentioned. To be honest, I don't believe that the switch is causing the issue, but the modem manufacturer said that this switch can actually pull the lines low somehow. Now we are planning the next version of the board, so I wanted to ask about it here to clear things up.

    The scope showed that signals (the CLK actually) are distorted on the MCU side of the switch, so it is impossible that the signals get distorted because of the switch, unless it is somehow capable of pulling the lines high or low on it's own. Otherwise, I'm pretty sure that the modem uses push-pull output to drive the IIC lines, and the strange voltages appear, because the modem tries to force out clock signals on the CLK line, while the MCU is trying to stretch the CLK low period. Unfortunately, I don't have simultaneous scope pictures from both sides of the switch now.

    The high-z function of the switch is working very well, altough there are pullup resistors only on the unprotected side of the switch. On the protected side, no pullup resistor can be placed, as the purpose of the switch is to cut voltage off the modem pins when the modem is powered off. Anyways, here is a schematic of the switch circuit part. The M66 2V8 is the output of the modem internal LDO, so - if the power of the modem is cut - the switch should automatically cut it's protected pins off the other parts of the system.

  • Thank for the additional detail Thomas.

    The SN74CBTLV3384 device shown above with a NFET in parallel with PFET does not have the ability to pull down the signal path on its own. The switch will either be on providing a low impedance path or off providing bus isolation or Hi-Z.

    In your scope plot I can see the "strange" 1.4 V voltage level you reference above. The switch will either be static on or off passed on the Vcc and OE voltages. Seeing that the signal temporarily drops to 1.4 V and then recovers tells me it is not likely the switch because the switch would effect all clock pulses the same.

    The best debug technique to rule out the switch is to remove it from the board short the trace and see if the problem persists.

    Let me know if I can answer additional questions.

    Thank you,
    Adam
  • Dear Adam,

    I'm working on replacing the MCU with one that surely can serve the modem without the need to use clock stretching. If tests with the new MCU won't be satisfactory, we will try to bypass the switch, but after your answer, I'm sure it has nothing to do with the problem.

    Thank you for your help!