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.

TS5A23159: Switch not responsive to changing inputs

Part Number: TS5A23159
Other Parts Discussed in Thread: TS3USB221

Hello, I am having an issue with a TS5A23159RSER SPDT switch deployed in a product. We are using the switch to pass either USB D+/D- or 3.3v UART Rx/Tx signals to a micro-b USB connector. We have heard back from several customers that the device is getting stuck in one state (normally-closed connected to common) and have determined that the problem lies in hardware rather than firmware. After swapping ICs between a known good unit and a failed unit, the issue tracked with the IC.

Have any issues have been reported for this batch of parts or are you are aware of another cause for this behavior? The UQFN-10 package is marked with "JE0."

  • Hello Brent,

    We are disappointed to hear about this problem, I have reached out to our quality engineer to confirm if he has seen any issues like this before.

    Our team had a few questions with regard to the use of the switch:

    1) Are you using the USB as actual USB or just for the port?

    2) If it is for this is for actual USB use, please confirm the data rate of your application complies with the bandwidth of the device speced in the datasheet, otherwise we cannot guarantee proper operation. See datasheet snippet below:

    3) If you are using this part for the actual USB protocol 480 Mbps, may we suggest the TS3USB221:

    Thank you for bringing this to our attention,

    Louie

  • Hello Louie,

    Thank you for the reply. The switch is used for Full-Speed USB 2.0 communication (12 Mbps). The same IC in TSSOP package has been deployed in the same configuration in another of our products since 2011 (~10k units sold) without seeing this failure.

  • Hello Brent,

    I have spoken to our quality engineer and there has been no report of such issues or returns.

    Could you give us a little more details as to how this device is being used or perhaps a schematic snippet of the device?
    Any details would help us debug this issue.

    Thank you,
    Louie
  • Here is an annotated snippet of the schematic with labels for the nets directly connected to the switch IC. The USB_SEL signal selects between Full-Speed USB and 31250-baud UART and the selected signals are passed to a micro-B USB connector. Vbus is bus power from the host device delivered via USB. The UART Rx/Tx signals are buffered by a non-inverting Schmitt trigger buffer with a supply voltage of 3.3V (from the same regulator that supplies the MCU).

  • Hello,

    You state that the Vbus is provided by a host, could you please provide the value?
    What are the voltage values coming from your D+ and D- inputs to the device?
  • It is connected to a standard USB port on a computer. USB spec states Vbus should be between 4.4 and 5.25 volts, and D+/D- between 0 and 3.6 volts. When in UART mode the connected device applies the same 4.4 - 5.25 volts to Vbus and D+/D- carry 0-5 volt UART.
  • Hello Brent,

    This sounds very peculiar, the voltage ranges for USB use sounds reasonable, however, I am a little concerned about the UART use case. Are there any instances where the UART signals themselves are higher than that of the VBus? If that is the case, there could be damage done to the device, as we specify that the  I/O's cannot be much higher than that of Vcc (Vbus in your case):

    If this is the case, could you provide some scope captures of your device of Vbus and the UART running?

    Thank you,

    Louie

  • Here are a handful of scope captures. The test transmission was a 'device inquiry' call-and-response initiated by the host. All signals look to obey the Vcc + 0.5 V maximum rating.

    Traces are as follows:

    • Ch1 - Yellow - Vbus
    • Ch2 - Blue - Tx (Device -> Host)
    • Ch3 - Pink - Rx (Host -> Device)

    The first capture shows the correct behavior on a known good unit.

    The second, from a returned unit, shows that the system doesn't receive the initial transmission from host to device.

    Manually prompting the device to transmit shows that the device can successfully transmit to the host.

  • Hello,

    Were these scope captures from known good or bad devices?
    When you pulled these, which pins did you measure them at?

    I apologize for not being more specific in the earlier post, I am trying to understand what could cause the device to be stuck in a specific state since my team hasn't seen this before. I appreciate your patience with me in this debug process.

    Thank you,
    Louie
  • The first capture is from a good unit and the other two are from a returned (bad) unit. The signals are measured at the midpoint of a USB cable with the cable signals broken out. I can retry with wires attached directly to the PCBA to rule out connector/cable issues if you'd like.

    Traces are as follows:

    • Ch1 - Yellow - Vbus - Pin 8
    • Ch2 - Blue - Tx (Device -> Host) - Pin 6
    • Ch3 - Pink - Rx (Host -> Device) - Pin 10

  • I repeated the experiment with the bad unit after soldering a USB cable directly to the USB connector traces on the PCBA and saw the same results.

  • Hello,

    Could you provide an additional scope capture between a known good and bad unit consisting of:
    NC
    NO
    COM
    IN

    But could you prove a scope capture as IN is transitioning from low to high. Please provide a continuous signal through COM, but drive the IN pin like how you are in your circuit with your MCU so that we can see if there is proper switching between the pins, and to make sure the IN pin is being properly driven from low to high.

    Thank you,
    Louie