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.

TUSB212: TUSB212 lead to QC charging fail

Part Number: TUSB212
Other Parts Discussed in Thread: TUSB216

Tool/software:

Dear team,

My customer find that when using TUSB212, QC charging may fail.  remove TUSB212 this issue disappear.

In QC charging, DM need to be pulled below 0.4V as in red circle below:

Passed case:

Red DP- After TUSB212

Yellow DP Before TUSB212

Blue DM after TUSB212

Green DM before TUSB212

However, in failed case, DM cannot be drive below 0.4V:

Customer remove TUSB212 and tested 100 times, no such issue.  happens on very unit they built.

Will TUSB212 add additional resistance on line so the drive strength is not enough?  Please hep to check on this issue.

Thank you.

Charles

  • Hi Charles,

    If the redriver is enabled during QC charging, then it will boost the signal, likely helping to prevent it from going below 400mV.

    Can the customer monitor the CD and ENA_HS pins to check whether the redriver is enabled or now?

    I am not familiar with QC charging, does this happen before or after a HS handshake/when a USB2 connection is made? If QC charging happens while a USB2 signal is made, then it is likely the signal is being boosted, preventing it from going below 400mV.

    The TUSB212 should not add any resistance to the lines.

    Thanks,

    Ryan

  • Hi Ryan,

    Customer used non I2C mode hence CD pin is not connected.

    Indeed it seems ENA_HS is toggling in failed case, and kept low in pass case.  How to solve this?

    Fail case 1

    Fail case 2

    Pass case

    Best,
    Charles

  • Hi Charles,

    Indeed it seems ENA_HS is toggling in failed case, and kept low in pass case.  How to solve this?

    Then it seems like the redriver is enabling sometimes during this QC handshake process, causing the signal to be boosted, and the signal to pass the required voltage level.

    In that case, I would recommend trying a newer redriver, like the TUSB216, and see if this issue is still present or not. There have been issues in the past with the TUSB212 enabling during a USB HS handshake, which has been corrected with newer devices, so it's possible switching to this device will fix it.

    Please let me know if you have any other questions.

    Thanks,

    Ryan

  • Hi Ryan,

    As also replied in email, customer (name in email) cannot switch to new device as this project is close to mass production.

    Please provide WA for this .

    Thank you

    Charles

  • Hi Ryan

    Attach pass fail case with CD pin:

    Pass:

    Fail:

  • Hi Ryan

    After removing TUSB212, the oscillation in both pass and fail case, as shown in red box below disappeared:

    Zoom in:, Seems indeed the TUSB212 is interfering with the signal. 

    Remove TUSB212, no such oscillaction:

    Please help to analysis ,

    Thank you

    Charles

  • Hi Charles,

    Then it does seem like the TUSB212 is enabling, yes. When does the QC handshake take place, before or after the HS handshake?

    One suggestion I would give, just to see if it will enable, is to hold the TUSB212 in reset during the handshake and then take it out of handshake afterwards to see if that improves the handshake performance and still allows the redriver to be boosted.

    Also, just to confirm while the TUSB212 is placed, holding the device in reset will help the signal pass as well, correct?

    Thanks,

    Ryan

  • Hi Ryan,

    Stage① is BC1.2 detection which is identified as DCP for this case;

    Stage② is QC2.0 detection (which is also called as HVDCP);

    In this case, there is no HS handshake considering that DCP has no data communication capability.

    Customer is able to get a clean waveform (no pulse) and QC charging by holding the device in reset

    Customer has few questions regarding TUSB212:

    1. Point ① ENA_HS  pin voltage is low level(asserted) which means this USB bus is in High Speed Mode (which is a wrong mode in this case),  actually , there is no TEST_PACKET or Chirp J/K signal , why this DC_BOOST/ENA_HS is asserted ? 
    2. Point ⑤  CD pin voltage is high level(asserted) which means connection detected, waveform shows no external voltage increment for DP/DM at this point , why this CD is asserted ?
    3. Point ⑥ , are these pulse (400mv,per 1.2ms) expected ? These pulse is used for AC boost ??
    4. For this issue , does this TUSB212 enter the Compliance Mode ? How to confirm the Compliance Mode State by ENA_HS and CD pin ? If TUSB212 enters to the Compliance Mode , what will this component do ? It seems it enable the extra PU resister on DM.....
    5. As your suggestion , holding RSTN low may help solve this issue. Could you share them more information about the "Compliance Mode" detection condition which may be very useful for us to find the good time to hold and release the RST_N for USB enumeration.
      1. When the RST_N reach to the VIH voltage , TUSB212 will start detecting the DP/DM state ? what's the time windows of this Compliance Mode Detection ? Maybe they could keep RST_N=0 only at this windows time to solve this issue and release the RST_N ASAP for USB enumeration.

    Please help to address, thank you.

    Charles

  • Hi Charles,

    Point ① ENA_HS  pin voltage is low level(asserted) which means this USB bus is in High Speed Mode (which is a wrong mode in this case),  actually , there is no TEST_PACKET or Chirp J/K signal , why this DC_BOOST/ENA_HS is asserted ?

    ENA_HS is high whenever the device is boosting the signal. In this case, ENA_HS goes low, which I believe is the expected result, as like you said, there's no test packets J/K chirp. When ENA_HS is low, the boost functionality should be disabled.

    Point ⑤  CD pin voltage is high level(asserted) which means connection detected, waveform shows no external voltage increment for DP/DM at this point , why this CD is asserted ?

    The CD pin detects when there is any USB connection made, whether that be LS, FS, or HS. It does not indicate, however, when the redriver is boosting. The ENA_HS is used for that functionality.

    Point ⑥ , are these pulse (400mv,per 1.2ms) expected ? These pulse is used for AC boost ??

    The redriver should not be enabled at this point, going by the ENA_HS pin. I'm not sure where those pulses are coming from, but given the redriver should not be boosting, I believe this may be coming from something else in the system.

    For this issue , does this TUSB212 enter the Compliance Mode ? How to confirm the Compliance Mode State by ENA_HS and CD pin ? If TUSB212 enters to the Compliance Mode , what will this component do ? It seems it enable the extra PU resister on DM.....

    The TUSB212 typically enters a test mode when used with the TEST_PACKETS command with the XHSETT program. The best way to tell is by monitoring the CD and ENA_HS pins. If the CD pin is low while the ENA_HS pin is high, that typically indicates the TUSB212 has entered a test mode of some sort.

    1. As your suggestion , holding RSTN low may help solve this issue. Could you share them more information about the "Compliance Mode" detection condition which may be very useful for us to find the good time to hold and release the RST_N for USB enumeration.
      1. When the RST_N reach to the VIH voltage , TUSB212 will start detecting the DP/DM state ? what's the time windows of this Compliance Mode Detection ? Maybe they could keep RST_N=0 only at this windows time to solve this issue and release the RST_N ASAP for USB enumeration.

    Yes, when the RSTN pin reaches the minimum threshold to consider the redriver enabled, then the redriver should begin monitoring the DP/DM lanes. As far as I am aware, there is no time window when it is looking for a compliance mode, or a test packet. It will just continually monitor the DP/DM lanes, and when seeing the waveform or pattern expected for a test_packet, it will enter that test mode.

    Like you said, hold the device in reset and then enabling it after any QC or BC1.2 handshake may help to correct this issue. They just need to ensure that the redriver is enabled in time to see that HS handshake take place.

    Thanks,

    Ryan

  • Hi Ryan,

    Thank you for the detailed reply.

    I am checking with the customer on the WA, but do you know why the device got enabled (boosted) at this time?  I can help to get more log if you need.

    Thank you,

    Charles

  • Hi Charles,

    I don't know the exact reason, this is an issue I have seen previously with this device however. Additionally, in most cases, this is fixed by using one of our newer redrivers, so I believe it was a known issue which was intentionally fixed with our newer redrivers.

    Thanks,

    Ryan