• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 34 subscribers
  • Views 1158 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TPS65986: BC1.2 Detection Delay

Eric S
Expert 5640 points

Part Number: TPS65986

This question is broken down into 2 pieces, each of which causes some system challenges for us:

  1. Is there a way to improve USB detection to prevent TPS65986 from reporting SDP connected first, then a little bit later after completing BC1.2 detection, update that report to CDP/DCP?   This change in connected device reporting can cause our system to temporarily drop Host connection, and the initial SDP reporting can also cause problems with system booting due to the associated current-limit setting for SDP.
  2. We have been told that 1-second should be sufficient for TPS65986 BC1.2 detection....  this is a pretty simple detection specification, can this be reduced somehow, with FW update perhaps?  

  • 0
    TI__Expert 4415 points
    Hi Eric,

    I will look into it and do the test, and then give feedback to you asap!

    Best Regards,
    Hao
  • 0
    TI__Expert 4415 points

    Hi Eric,

    I'm sorry we cannot change the BC1.2 detection timing in the TPS65986. It is not a configurable field. Our internal firmware will automatically handle the BC1.2 detection in the method shown in the picture below:

    I hope this helps and If this answers your question, PLEASE select  This resolved my issue 

    Best Regards,

    Hao

  • 0 in reply to Hao Wang14
    TI__Expert 5640 points

    Hao,
    What is not clear from this is:

    1. Do we need to report SDP initially, then BC1.2?   Is that essentially a state-machine that has to step through those reported connections, or could we wait to report anything until we know if there is any D+/D- detection present?  
    2. How long does it really take us to detect BC1.2, once a valid connection is detected?   I believe this is just voltage checking with resistors put on D+/D-, should be very fast, right?   Have we any characterization for how long this BC1.2 detection actually takes after valid connection detected?

  • 0 in reply to Eric S
    TI__Mastermind 30000 points

    Hello Eric,

    For the BC1.2 protocol, there are three different configurations you can be in. DCP, CDP, and SDP. Below is diagram showing the different configurations for these. DCP does not  allow for data transfer while SDP and CDP do.

    As far as the timing of connection type, yes it is very quick. Here's a CDP timing diagram example found within the BC1.2 specification. The portable device starts the conversation by sending a signal on the shared D+ line.  The source device detects this, and sends a response back on the D- line. The Portable device receives this response, and to verify that the D+ and D- lines are not shorted together (DCP mode), it sends another signal back through the D- line. The source device receives this signal through the D- line, but does not send back a response. Since the portable device never received a signal back on the D+ line, it knows that the D+ and D- lines are not shorted together, thus it is in CDP mode.

    I've also attached a copy of the BC1.2 spec sheet, which covers a lot of this information into more detail.

    BC1.2_FINAL.pdf

    If this answers your question, please click This resolved my issue

  • 0 in reply to Adam Mc Gaffin
    TI__Expert 5640 points

    Thank you, I now understand there is a series of events that must occur for primary and secondary detection.   However, the 1s is the max time that a PD must perform BC1.2 detection when plugged-in, doesn't necessarily mean that is how long we need to take, right?   Relevant timing for faster detection is TVDPSRC_ON + TVDMSRC_DIS + TVDMSRC_ON (40ms + 20ms + 40ms), not TSVLD_CON_PWD, right? The charger is only given 20ms to respond to DP/DM going high, which the portable device checks 40ms after it has turned on DM/DP in order to give the charger an additional 20ms buffer.
    Thus no more than 100ms should be “required” (120ms if we also give a 20ms buffer for the charger to turn off DM in response to DP going low).   Why does TPS65986 not begin BC1.2 detection immediately after VBUS is present?   Realizing that it may also depend on the Charger, not just our PD, but am I understanding the timings correctly, and doesn't it seem feasible that we should be able to complete detection significantly faster than 1s?    I appreciate your further clarification.

  • 0 in reply to Eric S
    TI__Mastermind 30000 points
    Hi Eric,

    We spoke on the phone last week, so I'm just replying to this post to close this forum. I also want to provide the same information that I provided to you over the phone, on here for others to see in case someone has a similar question.

    As far as why theTPS65986 takes a full second to finish BC1.2 detection while the specification only shows 100ms is because the TPS65986 is a Type-C PD controller first and a BC1.2 device second. Its primary objective is to negotiate over the CC lines to determine the voltage it should supply to the sink device. All USB Type-C to legacy cables have a internal pull up resistor, which the TPS65986 detects and supplys 5V over VBUS since VBUS is always on for BC1.2. Then, the sink device begins the BC1.2 negotiation which the TPS65986 detects and then responds to. This is where the extra time is going.