• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 34 subscribers
  • Views 806 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: VBUS resets on PD register write

Joshua Johnson
Prodigy 41 points
Other Parts Discussed in Thread: TPS65987D

I have a board with the TPS65987D PD Controller IC on it, and it is being configured over I2C from an Atmel SAM4S processor. I am probing VBUS as I write the registers, and VBUS is reset from the external power brick after two of the five registers I write to. My problem exists in the "dead battery state" where there is no internal power available to keep the system powered while VBUS is resetting. My goal is to successfully negotiate a high-power contract with the external power brick to charge a dead battery and/or run the system without a battery,

The two registers I am writing to that are causing this behavior are as follows:

  • 0x27: Global System Configuration
    • Value written: 0x09000000140080001200120000
  • 0x28: Port Configuration
    • Value written: 0x001E2D179FFE0000

Below are two o-scope captures showing the behavior:

Yellow: Write over I2C from SAM4S to TPS65987D-> register 0x28

Green: VBUS resetting, losing system power (as measured at the USB-C connector on the board)

Yellow: I2C_SCL on write to PD Controller

Green: I2C_SDA on write to PD Controller

How do I prevent the VBUS reset from happening?

Thanks,

Josh J

  • 0
    TI__Mastermind 36756 points

    Hi Josh,

    This is the expected behavior when you change those two registers. In the Host Interface TRM, the following note can be found under those two registers: "Note: Any modifications to this register will cause a port disconnect and reconnect with the new settings."

    This behavior is expected.

    If this answers your question, PLEASE select This resolved my issue

    Thank you,
    Eric

  • 0 in reply to Eric Beljaars
    Prodigy 41 points
    Hello Eric,

    It was my understanding that this would remove power *through* the PD controller, but I didn't expect it to reset the external power from the power brick.

    If the register values are maintained in the PD controller despite losing all power to the PD controller for the ~800 ms it takes for VBUS to return, then we should be able to work with that by reading the registers and only writing if they are not set correctly. We would have to go through 2 hard-resets on our SMP due to power losses, but it would be workable.
  • 0 in reply to Joshua Johnson
    TI__Mastermind 36756 points
    Hi Josh,

    The PD controller does a disconnect and reconnect so that it can renegotiate with the new settings that were changed. If you are powered from VIN_3V3 then the changed settings will remain. If you are powered only from VBUS then the settings will be overwritten to the default settings after disconnecting and reconnecting.

    Thank you,
    Eric
  • 0 in reply to Eric Beljaars
    Prodigy 41 points
    Hello Eric,

    We do have the ability of powering VIN_3V3 with our system when we have charge remaining in our battery. In that case, we are able to configure and use the PD controller as expected. However, when the battery is dead and we have no internal system power, so we can't maintain VIN_3V3.

    Is there a way to negotiate the high-power contract we need, using I2C to configure, without using internal power? If not, it doesn't seem as though we can recover from a dead-battery state with the way we are using the PD controller.

    Thanks,
    Josh Johnson
  • 0 in reply to Joshua Johnson
    TI__Mastermind 36756 points
    Hi Josh,

    In a dead battery condition, you could set the default configuration to a 20V sink contract so that you can recover from dead battery mode. Then once your VIN_3V3 supply is stable, you could rewrite the register settings over I2C.

    Thank you,
    Eric
  • 0 in reply to Eric Beljaars
    Prodigy 41 points
    Hey Eric,

    Okay, I think that makes sense. We will either need to use the 20V contract via strapping options or load a different configuration via SPI flash (which we do not have on the board at this time)

    Thanks Eric!
    Josh Johnson