• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 4 answers
  • Subscribers 32 subscribers
  • Views 3225 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TPS65982: Asking for the 982 for monitor and Notebook application

SHH
Mastermind 31126 points
Part Number: TPS65982

Hi Team,
Customer uses TPS65982 on both type C monitor(60W) and type C notebook side.
For the VCONN function, which deivce should provide the VCONN power to the cable?

Due to both monitor and NB are DRP mode, I suppose to that NB should provide the VCONN power.
The reason is that the NB will be the DFP data role. So eventually, the VCONN power is from NB side.
Please correct me if incorrect. Do you have spec or something that describe this behavior in detail?


Thanks,
SHH

  • 0
    TI__Guru 50120 points

    Hi SHH,

    The DFP will be providing VCONN power to the cable. Below in Table 1 of datasheet shows the the actions that happen during attachment when TP65982 is configured as DFP. 

    Regards,

    Jimmy Hua 

  • 0 in reply to Jimmy Hua
    TI__Mastermind 31126 points

    Hi Jimmy,

    Thanks for feedback.

    For the VCONN sawp case, DRP role monitor sometime will be DFP first whiling connecting to NB.

    And DFP monitor and UFP NB will do the data role swap (UFP monitor and DFP NB). After data role swap, it will follow by the VCONN swap.

    So VCONN will probide by monitor fisrt. In the end, NB will provide the VCONN to the cable. Is that right?

    During the VCONN swap, will the voltage keep at 5V during transition time? Or 5V will drop and the emaker IC will be reset?

    Thanks,

    SHH

  • 0 in reply to SHH
    TI__Guru 50120 points

    Hi SHH,

    Yes that is correct. Initially the monitor will provide VCONN but then there will be a VCONN swap that will change it's role from source to sink. In that case, the monitor will be the sink, and the attached device will be the source. The voltage is expected to drop and reset back. 

    More information on the process flow can be read in the USB PD rev1.2 document under the section "Table 8-21 Steps for USB Type-C Source to Sink VCONN Source Swap". 

    Regards,

    Jimmy Hua 

  • 0 in reply to Jimmy Hua
    TI__Mastermind 31126 points

    Hi Jimmy,

    this is the CC1/CC2/VBUS waveform.

    you can see there are three communication. First and third communication can establish the VBUS 20V perfectly.

    The monitor will send HRSET to TPS65982, so you will see the CC communication will communicate again.

    The question is the CC2(CH3) voltage weird after the second communication. It go to high 5V and go back to 0V.

    Q:

    1.Could you provide your commend for this case?

    2.Any concern for no 5V on CC2? According to lecroy log, both monitor and NB can establish 20V and enter DP alt. mode normally.

    CC1: CH2

    CC2:CH3

    VBUS:CH1

    Thanks

    SHH

  • 0 in reply to SHH
    TI__Guru 50120 points

    Hi SHH,

    I'd like to restate your setup to make sure I'm understating correctly. The waveform you have on the scope is on the "monitor" side using the 982EVM set as DRP. You have another 982EVM connected set as DRP. In the first case, the monitor side 982EVM will  act as the source and supply VCONN, then a VCONN swap happens, and then the attached 982EVM will become the switch from being a consumer to being a provider that supplies VCONN.

    If that is the case, the waveform you have shown is fine regarding the CC2 line. It is expected that the CC2 line on the "monitor" side 982EVM have VCONN turned off. 

    Can you provide the Lecroy log so I can take a look at it?

    Regards,

    Jimmy Hua 

  • 0 in reply to Jimmy Hua
    TI__Mastermind 31126 points

    Hi Jimmy,

    The waveform is on the NB 982D side. both monitor 982 and NB 982 are set as DRP. It can only duplicated on the emark cable.

    the lecroy trace good and bad are the same. I cannot tell different from the lecroy trace. both traces can enter DP mode successfully. however, 982D in NB side do not sent the interrupt to AR chip to update the alt mode. So the fail happen, the intel will not send out the DP signals. (fail rate: 30%, each 982D NB has the same fail rate)

    here is the traces.

    monitor_NB_NG.usb

    monitor_NB_OK.usb

    Thanks,

    SHH

  • 0 in reply to SHH
    TI__Guru 50120 points
    Hi SHH,

    I'm still looking into this and will get back to you soon.

    Regards,
    Jimmy Hua
  • 0 in reply to Jimmy Hua
    TI__Guru 50120 points

    Hi SHH,

    Can you provide information on the PD Status(0x40) HardResetType register from the Host Utilities GUI? 

    Regards,

    Jimmy Hua 

  • 0 in reply to Jimmy Hua
    TI__Mastermind 31126 points

    Hi Jimmy,

    I do not have this registers on hand. But I can confirm that 0x5F DPPinAssignment is going to C.

    Can you explain why need to check this register 0x40? from the lecroy trace, both NG and good are communicate and enter altenate mode.

    Thanks,

    SHH

  • 0 in reply to SHH
    TI__Guru 50120 points
    Hi SHH,

    I ask this for more information on the two hard reset that you mentioned from your oscilloscope. When I look at your lecroy traces, they appear to be similar.

    I'd like more clarification on what the "good" and the "bad" situation is.

    Regards,
    Jimmy Hua
  • 0 in reply to Jimmy Hua
    TI__Mastermind 31126 points
    Hi Jimmy,
    "good" and "bad" means whether the NB can detect the monitor and display on the monitor.
    For the bad case, NB cannot detect the monitor and send the DP signal to monitor.
    TBT only read the USB device on the type C port.
    However, both "good" and "bad" case, the PD communicat can enter alt mode in DP assignment C.

    Thanks,
    SHH



    Thanks,
    SHH
  • 0 in reply to SHH
    TI__Guru 50120 points

    Hi SHH,

    Can you confirm that the Data Status Update is enabled in your Interrupt Event Mask?

    Also can you provide a scope-shot of the I2C lines during a good and bad case? Looking at this will help me understand if the interrupt is being sent properly over the I2C line.

    Regards,
    Jimmy Hua

  • 0 in reply to Jimmy Hua
    TI__Guru 50120 points
    Since this has not been replied to, I would like to close this thread. If you have any further questions, please reply and comment.

    Regards,
    Jimmy Hua