• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 63 subscribers
  • Views 555 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.

TPS65987D: Power Delivery Test TD4.1.2 fails

Koichi Tsuchida
Prodigy 10 points
Part Number: TPS65987D

Hello, to whom it may concern,

I am currently designing PD3.0 source system using TPS65987D with three PDOs 5V,9V,15V each 3A capability. And recently I had taken PD certification test for our product.

Unfortunately there were failed in TD4.1.2 unpowered CC voltage with error message;

"Error Message: TD.4.1.2.V.3, TD.4.1.2.V.5, TD.4.1.2.V.7 The PUT's CC voltage is not in vOPEN range." 

Result:  934mV < min 1.65V spec, @ Default Rp/1.5V@Rp,  1.65V < min 2.75V spec @ 3A Rp.

The test had conducted in other testlab (using LeCroy M310e), but we don't have M310e so that I tried to reproduce the symptom by using very simple method, just plug/unplug the sink device(USB-C-PD-DUO-EVM, SNK mode)

The test results I had done are different from the results obtaind by testlab, the vOPEN is around 3.3V stable.

The question is how I should do a similar test condition to be like M310e  ? 

Or is there any trick to change VIF/*.pjt file to improve vOPEN voltage (or somehow..) ??

I am ready to send VIF/*.pjt file to you but It may have confidential info so please let me know if you have any comments.

Regartds,

Tsuchida 

  • 0
    TI__Genius 12905 points

    I think if you are seeing different/passing results from different test equipment, I believe the testlab should take your results into account and rule this as possible tester issue. 

  • 0 in reply to Christodulos Tsongas
    Prodigy 10 points

    Hi Christodulos-san,

    Thank you for your prompt reply. May I ask what does it mean?

    To be honest I am not familier with Type-C test rule and condition so then I will ask our testlab with your further comment.

    Thank you once again and regards.

    Tsuchida

  • 0 in reply to Koichi Tsuchida
    Prodigy 10 points

    Hi Christodulos-san,

    I have received additional info from our testlab, they used GRL-PD-C2-EPR link  and regretfully it was also failed.

    This is just for your information only..

    Regards, Tsuchida

  • 0 in reply to Koichi Tsuchida
    TI__Genius 12905 points

    Koichi,

    Please share the following:

    Your configuration file (.pjt) 

    What version of Application Customization Tool you are using

    GRL/Lecroy failing logs 

  • 0 in reply to Christodulos Tsongas
    Prodigy 10 points

    Hi Christodulos-san,

    Heres are the versions of the test systems, and zip is the configuration file.

    LeCroy M310e
    USB Compliance Suite Version 7.65 Build 1170
    USB Protocol Suite Version 9.30 Build 4549
    Analyzer Voyager M310e 23670: BusEngine 3.09 Firmware 4.05

    GRL-PD-C2 tester
    GRL_USB_PD_Controller_Serial_No GRL-C2-EPR-2022081240208.zip
    GRL_USB_PD_Software_Version 1.6.22.0
    GRL_USB_PD_Firmware_Version 1.1.94
    GRL USB-PD Ethernet Buffer Size 62K
    GRL USB-PD Eload Firmware Version 1.5 / 1.5
    GRL USB-PD PPS Firmware Version 4.0 / 4.0

  • 0 in reply to Koichi Tsuchida
    TI__Genius 12905 points

    Koichi,

    I see in your project you have Port Control -> TypeC Current = 3.0A which means we are setup by default to advertise 3.0A Rp value. 

    There are 2 potential reasons you may not be seeing the advertisement as 3.0A:

    1. Your EC/MCu may be modifying register 0x29 and changing this value
    2. TPS65987D may not be in APP mode which could cause this behavior. 

    Otherwise I cannot debug further without the GRL/LeCroy logs. 

    Thanks,

    Chris

  • 0 in reply to Christodulos Tsongas
    Prodigy 10 points

    Hi Chris-san,

    Thank you for your kind analysis and comments. I have also checked register setup of our target board that shows working properly, 

    0x03 shows "APP" so that the PD controller is functioning I think.

    In our target board, the host CPU does not have any controll connection such as I2C or SPI, so the PD controller is just prepared for PD function.

    So I think the comment 1 would be negative. But the comment 2 we didn't get any operation logs of our target board and PD controller at that certification test. 

    We may ask our testlabs to provide us the test log for this troubleshooting and I think we may take brief testing with TPD-EVM to check operation register 0x03 of on-board PD controller. Is there any good approach ? Please give us your comment.

    Thank you once again and best regards,

    Tsuchida

    PS　We will have holidays by 6th May, so please accept my apologize for delaying response..

  • 0 in reply to Koichi Tsuchida
    TI__Genius 12905 points

    PD logs from the tester would be ideal. I will send you friend request so you can send them off of a public forum. 

    Also if you do have the EVM that is a good way to test this. I suspect this is tester issue but cannot verify without logs.