• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 376 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.

TPS65986: TPS65986 compatible issue on Dell Vostro 5471, HP ProBook 440G5 and Clevo N150ZU

Gary Teng
Genius 5190 points

Part Number: TPS65986

Hi all,

 We have compatible issue about PD connection in TPS65986 PDO 20V3A to some NB. We test different version FW (from 1.11.02 to 1.38.06), modify peak current setting to 200% but can't solve the issue.

But when we test those NB by using some other 983B dock, those NB can be charged (through PPEXT). 

Is this relative with PD's OCP issue or other projection in 986? Or anything we can check at customer's board to confirm the issue? 

We can provide log data for reference if necessary.

Best regards,

Gary Teng

  • 0
    TI__Mastermind 27535 points

    Hello Gary,

    Do you believe an over current event is occurring? If so, recommend capturing the VBUS voltage and current during the failure to try and isolate the issue.

  • 0 in reply to Adam Mc Gaffin
    Genius 5190 points

    Hi Adam,

     I'm not sure what's happened... We monitor Vbus but don's see abnormal voltae/current spent and it's a little hard to measure pphv input power. Or any other question we can check at customer's board?

    Best regards,

    Gary

    0325_16A0_101_Dell5471.7z

  • 0 in reply to Gary Teng
    TI__Mastermind 27535 points

    Hi Gary,

    I would recommend that you decrease the time scale so that you may better see the failure case. With the time scale being so long, you could miss the over current event' Recommend setting up a trigger event on the oscilloscope to where to triggers a capture on the falling edge of VBUS.

    Also, to help isolate where the failure is coming from, recommend looking at registers 0x14 - 0x19. These are the interrupt event registers, and will help indicate whether a over current event is occurring or if it could be something else.

    Finally, I would recommend measuring the voltage on PPHV as well as VBUS

  • 0 in reply to Adam Mc Gaffin
    Genius 5190 points

    Hi Adam,

     We monitor PPHV signal by using EVM with customer's bin, and see different result:

    1. there's large current when 20V start with HP NB. Is it trigger OCP in PD?

    2. No current output when connecting to Dell NB:

     So is there other issue in PD communication? We have snapshot data. Would you please helping to check it and give us suggestion? Thanks.

    982_pphv_dell.zip

    Best regards,

    Gary

  • 0 in reply to Gary Teng
    TI__Mastermind 27535 points

    Hello Gary,

    This is your problem. The large current spike you captured is triggering the OCP functionality. This is not a problem of the TPS65986 but instead the laptops that are being connected. The current spike almost reach 12A which is double your over current threshold you have set (200% of 3A = 6A). There is no way to resolve this as the TPS65986 will continue to see this as a over current event and the laptops will continue to pull the 12A of current that they are pulling.

  • 0 in reply to Adam Mc Gaffin
    Prodigy 30 points

    Adam Mc Gaffin said:
    ,

    There is no way to resolve this as the TPS65986 will continue to see this as a over current event and the laptops will continue to pull the 12A of current that they are pulling.

    Hi Adam,
    Thanks for your reply and debug guidance.
    I am Chamber who work with Gary for this issue. We understand the HP ProBook 440G5 is suspicious and hit over current protection.
    Here  we are talking another laptop - Dell Vostro 5471 which suffer different situation from HP 440G5.
    As you may see packet #135 reach "PS Ready". We realize there is no current output from PP_HV after that.
    We also capture register log 0x14 - 0x19 as you mentioned for your review. May please advise what should we do to look into this issue?
    Attach please find the I2c register log file and Lecroy packet file. Hope this helpful for our discussion. Thanks!
    Regards!
    Chamber Wang
  • 0 in reply to Chamber Wang
    TI__Mastermind 27535 points

    Hello,

    Would you be able to have a longer oscilloscope capture? Showing the initial connection to the laptop, 20V being negotiated on VBUS, and then the eventual disconnect. Also, are you able to read the interrupt register after the event to see if a fault occurred after the disconnect?

  • 0 in reply to Adam Mc Gaffin
    Prodigy 30 points

    Hi Adam,

    Adam Mc Gaffin said:

    Would you be able to have a longer oscilloscope capture?

    Showing the initial connection to the laptop, 20V being negotiated on VBUS, and then the eventual disconnect.

    Thanks for your reply. We will capture the scope to see the whole procedure from 20V negotiated to disconnected.
    Adam Mc Gaffin said:
    Also, are you able to read the interrupt register after the event to see if a fault occurred after the disconnect?
    May I know how? As the PD negotiation will try next PD negotiation once VBUS disconnected. Do you mean unplug the type C cable once "VBUS disconnected" then read interrupt register immediately?
    How may I keep the status in fault  instead of next trying?
    Regards,
    Chamber
  • 0 in reply to Chamber Wang
    TI__Mastermind 27535 points

    Hello Chamber,

    If possible, the easiest method would be to place a logic analyzer on the I2C channel between your EC and the PD controller. If possible, a Saelae logic analyzer would be best so you can capture VBUS, ISC_SCL, I2C_SDA, and I2C_IRQ. However, any logic analyzer will do. Assuming that your EC interacts with the PD controller, you should see the IRQ line go low, and the EC should read the IRQ register to determine what caused the fault. Reading this interaction will tell you what the fault event was during the drop on VBUS.

    Let me know if you have any other question or nee any help

  • 0 in reply to Adam Mc Gaffin
    Genius 5190 points

    Hi Adam,

     There's no EC connected with 986 in this case. We have ever get snapshot data by GUI debug mode in previous post for Dell case. Is that help to check status register?

    Best regards,

    Gary

  • 0 in reply to Adam Mc Gaffin
    Prodigy 30 points

    Hi Adam,

    Adam Mc Gaffin said:

     If possible, a Saelae logic analyzer would be best so you can capture VBUS, ISC_SCL, I2C_SDA, and I2C_IRQ

     EC should read the IRQ register to determine what caused the fault. Reading this interaction will tell you what the fault event was during the drop on VBUS.

    I try to capture  I2C_IRQ I2C_SCL, I2C_SDA and obtain IRQ with some high pulse at 2 sec.

    However, as Gary mention, there is no embedded controller on board, Therefore we are unable to read IRQ register at appropriate timing.

    Does TI recommend any EVB board with MCU so that we may implement s small ISR on it?

    Please advise if possible. Thank you.

    The saleae capture log was upload to following link for your information. (Total size > 200M so I upload to free cloud server)

    https://we.tl/t-6GFfTNfMju

    Regards

    Chamber

  • 0 in reply to Gary Teng
    TI__Mastermind 27535 points

    Hi Gary,

    Apologies, I thought there was an EC on this system. Yes, you can use the GUI tool in debug mode instead, no need for the logic analyzer.