Quantcast
Channel: Forums - Recent Threads
Viewing all articles
Browse latest Browse all 262198

TPS65986: Questions on use case of TPS65986 with charger

$
0
0

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?


Viewing all articles
Browse latest Browse all 262198

Trending Articles