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.

TPS65994AD: Source-only DFP design in dead-battery startup condition

Part Number: TPS65994AD


Hi,

We are debugging our source-role-only, no battery, DFP design on the EVM board in dead-battery startup condition and encountering the following issues:

  • When EVM is in dead-battery startup condition, the voltage on VBUS is oscillating. From PD analyzer logs it is observed the port is repeating VBUS down/up/negotiation periodically.
  • Applying external power to EVM would intermittently result in the port to indicate: 
    • Reg. 0x1A
      • PlugPresent = No plug is connected
      • ConnState = No connection
      • Port Role = Sink
      • Data Role = UFP
      • VbusStatus = less than 0.8V
    • Reg. 0x28
      • Type-C state machine = disabled (CC pins are hi-z)
    • Reg. 0x2D
      • Dead Battery Flag = True
    • No way to recover by any port un-plug/re-plug

(Sending 'Clear Dead Battery Flag' command could bring the port back to expected source-role-only, DFP state)

Question:

  1. We tried to change PD settings from 'source state machine only' to 'DRP state machine' which would prevent VBUS from oscillating and when external power applied to EVM the port connection is recognized. However, every time recovering from dead battery startup condition the port is always in sink role and UFP. How to configure the PD to always act as source only role and DFP when recovering from dead-battery startup condition?
  2. Does PD always rely on its host communication to send 'Clear Dead Battery Flag' command when recovering from dead-battery startup condition? In TPS65994AD design resource package, an UCMCx Win10 driver is included. Is this UCMCx driver implemented with the policy to send 'Clear Dead Battery Flag' command to PD once dead-battery flag is set?

The PD configuration under debugging is attached for reference.

Thanks,

Jonathan Liang

tps65994ad_evm_dbsc_20220316.pjt

  • Hello Jonathan,

    Is this following an Intel reference design? The TPS65994AD is intended to support USB4/TBT4 reference designs. Want to verify that you are using the correct device before we start diving into the issue itself. 

  • Hi Adam,

    Yes, this is an Intel reference design with EC-less USB4/TBT4 and TPS65994AD is recommended by Intel for the platform our design is based. 

  • Hi Adam,
    May I know that for Device Configuration mode for Source Only PD, what is the right setting for the ADCIN1 & ADCIN2.

    Intel has one reference design with Source Only PD with ADCIN1 =2 and ADCIN2=7.

    Our design is with ADCIN1 = 7 and ADCIN2 = 0.

    We have try with ADCIN1=7 and ADCIN2 = 4, with the same I2C address but bring us into Dead Battery Config with Sink_Require_3.0A. Similar config with Intel reference design.
    This mode also not working with self Power USBC. 

    Please let us know if any of the Port Config and Port Control setting to avoid the VBUS from oscillating. 

    regards,
    LT

  • Hello,

    You will need to generate a PD controller firmware image using the GUI available in the secure site for the TPS65994AD. You cannot have USB4 operation without generating the PD controller firmware image using the GUI. This image would then be stored on an external EEPROM for the PD controller to load during operation. Without this PD controller firmware image, the device will not behave as expected and could have unexpected behavior. 

  • Hi Adam,

    LT Lee and I are working on the same project which is based on an Intel reference design. tps65994ad_evm_dbsc_20220316.pjt is the PD controller firmware image generated by the GUI for your reference. Would you help to look into the issue, please?

    5277.tps65994ad_evm_dbsc_20220316.pjt

    thanks,

    Jonathan Liang

  • Hi Jonathan,

    How are you loading the PD firmware binary image onto the TPS65994AD? Are you using an external EEPROM? How are you loading the binary eeprom onto the EEPROM?

  • Hi Adam,

    • On our target system:
      • We use external EEPROM to carry the PD firmware binary
      • The binary is loaded onto the EEPROM using an external programmer
      • ADCIN1 = 7, ADCIN2 = 0
    • On the EVM:
      • We load the PD firmware binary to the EEPROM on the EVM
      • The binary is loaded onto the EEPROM using the GUI and TIVA host on the EVM
      • ADCIN1 = 7, ADCIN2 = 0
  • Hi Johnathan,

    Thank you for the information, will get back to you as soon as possible.

    Regards,

    Tommy

  • Hello Johnathan,

    After running the project you provided on my end, everything looks fine and we did not see the VBUS oscillating on our broad. The PD log captured by Teledyne LeCroy T2C is attached below.

    From the description you given, I suspect that there are some damage to the power circuitry of the EVM that caused the VBUS oscillation. Please contact your FAE to get a new board.

    Please note that this part has IP restriction therefore we cannot provide much support on public forum. You can go through your FAE for internal support.

    Regards,

    PD_log.pdf

  • Hi Tommy,

    Thank you very much for trying out the PD configuration we attached and providing the PD log. We will look into the log and compare with our result.

    Below test setup could create VBUS oscillation on our EVM board.

    • 5277.tps65994ad_evm_dbsc_20220316.pjt loaded
    • ADCIN1 = 7, ADCIN2 = 0
    • No 20-V barrel jack adapter, no DC power supply applied to EVM (VIN_3V3 = 0V)
    • A self-powered Type-C device (TBT dock, Type-C monitor) plugged to one of EVM Type-C ports

    Then, applying 20-V barrel jack adapter input to our EVM and below failed scenario would occur intermittently (50%):

    • Reg. 0x1A
      • PlugPresent = No plug is connected
      • ConnState = No connection
      • Port Role = Sink
      • Data Role = UFP
      • VbusStatus = less than 0.8V
    • Reg. 0x28
      • Type-C state machine = disabled (CC pins are hi-z)
    • Reg. 0x2D
      • Dead Battery Flag = True
    • No way to recover by any port un-plug/re-plug
    • Sending 'Clear Dead Battery Flag' command could bring the port back to expected source-role-only, DFP state

    Were you doing the same on your EVM when you found everything looking fine on it?

    We do not have TI local FAE support at the moment. We were trying to reach out to a TI local sales contact for an FAE support on this part, however were advised to interact with TI AE support on E2E forum.

    I have requested to connect you on E2E in order to continue the discussion of this post through private message. Please help to check the connect request.

    Thanks,

    Jonathan

  • Hi Johnathan,

    Please check your message.

    Regards,

    Tommy