• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 2010 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.

TPS65986: Questions on use case of TPS65986 with charger

Wes Byers
Prodigy 410 points

Part Number: TPS65986

Hello,

We have been working with our TPS65986 and have been having some weird role swap issues when plugging in a Hub/charger.

 

We have been working on getting UFP / DFP modes working with their SOC's USB device/mode switching.  We want our device to normal be in DFP / Power Sink / SOC in Host mode.  We want to allow transitions to UFP / Power Sink / SOC in Device mode for debug & development purposes.

 

So far, We have two problems:

 

1) Connecting https://www.anker.com/products/A8302041 to our DUT, sometimes the TPS65986 register 0x1A will report byte 0 as 0x5d (DR = DFP, PR = Sink) as we want.  However, sometimes it reports 0x6d (DR = DFP, PR = Source).  No idea how we'd end up as a source.  I don't have 'Process swap to Source' or 'Initiate swap to Source' enabled in the FW.  Any ideas why TPS65986 would report us as a source? What is the best way to debug this?  

 

2) Having a problem with PD negotiations still occurring while the kernel driver is handling interrupts.  Basically, we get an interrupt when I plug in a cable (with a device such as another TPS65986 EVM or the Anker on the far end) and the kernel driver checks the 0x1a register, which reports 0x1d (DR = UFP, PR = Sink).  Since this is a development build, we allow UFP mode, so we notify our SOC USB driver to start the switch to device mode.  The switch is asynchronous as it requires various transitions through their state machine.

 

As this transition is occurring, another interrupt fires since the 0x1a register has updated to have the value of 0x5d (DR = DFP, PR = Sink). At this point, we tell the SOC driver to transition to host mode.  This request is ignored since it is still transitioning to device mode.

 

Wanted to know:

-- Why do we see the status going from 0x1a -> 0x5a a short time after the cable is attached?  Is that just due to the time it takes to do PD negotiations?

-- Is there a single interrupt that we can use to know know when the cable state is fully detected (regardless of BC1.2 being used, or PD)?  

-- If the change in status is due to PD negotiations, is there a way for us to know that a PD-capable device is attached and that negotiations are still in progress?

  • 0
    TI__Guru 50120 points

    Hi Wes,

    Do you have a Lecroy PD analyzer that can capture the PD messages being sent in your system? I'd also like to have your project and bin files so I can try to recreate the issue with your setup here. 

    Regards,

    Jimmy Hua 

  • 0
    TI__Guru 50120 points
    Hi Wes,

    For the TPS65986EVM, what is the S1 Switch configured as? Also is your system setup something like PD adapter connected to Anker HUB which is then connected to TPS65986EVM?

    I'd like to get a better picture of your setup to help understand where there might issues.

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

    Can you clarify on what the 0x1A that you talked about in your original post is referenced to. 0x1A is a status register based on the Host Interface documentation, but you stated that "status goes from 0x1A to 0x5A" after cable attach.

    As for the cable fully detect, I'm assuming you are wondering when plug is present. If that is the case, you can look at the IntMask value to check for a Plug Insert or Removal Event or byte 0 of register 0x1A for Plug Present.

    Regards,
    Jimmy Hua
  • 0 in reply to Jimmy Hua
    TI__Intellectual 2385 points

    Jimmy Hua said:
    Wes,

    Can you clarify on what the 0x1A that you talked about in your original post is referenced to. 0x1A is a status register based on the Host Interface documentation, but you stated that "status goes from 0x1A to 0x5A" after cable attach.

    As for the cable fully detect, I'm assuming you are wondering when plug is present. If that is the case, you can look at the IntMask value to check for a Plug Insert or Removal Event or byte 0 of register 0x1A for Plug Present.

    Regards,
    Jimmy Hua

    Hi Jimmy,

    Sorry that was a typo, it was meant to read "Status register (0x1A) goes from 0x1d to 0x5d after cable attach"

    For the plug insert GPIO, will it immediately switch to 1 upon plug insertion, or after cable orientation and power negotiation is actually complete?

    Thanks,

    Josh

  • 0 in reply to Jimmy Hua
    TI__Intellectual 2385 points

    Jimmy Hua said:
    Hi Wes,

    For the TPS65986EVM, what is the S1 Switch configured as? Also is your system setup something like PD adapter connected to Anker HUB which is then connected to TPS65986EVM?

    I'd like to get a better picture of your setup to help understand where there might issues.

    Regards,
    Jimmy Hua

    Hi Jimmy,

    Yes, that is correct, PD adapter -> HUB -> EVM. And the switches are set to 1000.

    Thanks,

    Josh

  • 0 in reply to JoFu10
    TI__Guru 50120 points
    Hi Josh,
    The plug insert GPIO will immediately switch to 1 upon plug insertion. There will be an expected minimum debounce time (100ms).
    Regards,
    Jimmy Hua
  • 0 in reply to Jimmy Hua
    TI__Guru 50120 points
    Hi Wes,

    I've taken a look at the Total Phase files you sent. What exactly is the usb-pd-ank-DUT-source file meant to represent? The PD trace on that shows that there were no connection established and the CC lines are toggling in that event.

    Regards,
    Jimmy Hua
  • 0 in reply to Jimmy Hua
    TI__Intellectual 2385 points
    Hi Jimmy,

    Please just use the sink file as it should have both sink and source messages there.

    Also, what would be the easiest way to indicate when the TPS65986 is done detecting its data/power role for of the cases we'd want to support (PD supported, PD not supported, BC1.2 supported, etc)? The plug event GPIO only detects when there is a plug inserted, but not when the data and power role negotiations are complete.

    Thanks,
    Josh
  • 0 in reply to JoFu10
    TI__Guru 50120 points
    Hi Josh,

    In Debug Mode, you can check the system configuration section(0x28) under Configuration Registers to verify BC 1.2 Enable status and other desired register values. You can also go into Debug Registers tab and Power Status section to check BC1.2 Status and Data Status section for USB2/3 Connections and data role information.

    Regards,
    Jimmy hua