TPS65982: charger disconnect

So the low currents in the RDO are caused by putting the firmware into SNKIntrusiveMode mode. Reading the "host interface technical reference manual" section 2.3 would lead one to believe that unless the host gets involved and sends and SRDO task that the RDO should be the same. This doesn't seem to be the case.

Putting the TPS65892 into SNKIntrusiveMode changes the values in the AUTO sink negotiation register

Without SNKIntrusiveMode set

[   82.418579] tps6598x 0-003f: tps6598x_print_auto_sink: Fixed PDO
[   82.424627] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO
[   82.430838] tps6598x 0-003f: tps6598x_print_auto_sink: Variable PDO
[   82.437136] tps6598x 0-003f: tps6598x_print_auto_sink: no USB suspend flag
[   82.444042] tps6598x 0-003f: tps6598x_print_auto_sink: give back flag
[   82.450508] tps6598x 0-003f: tps6598x_print_auto_sink: auto compute min sink power
[   82.458100] tps6598x 0-003f: tps6598x_print_auto_sink: highest power
[   82.464479] tps6598x 0-003f: tps6598x_print_auto_sink: min sink power 12000 mW
[   82.471725] tps6598x 0-003f: tps6598x_print_auto_sink: RDO power 0:0 mW
[   82.478363] tps6598x 0-003f: tps6598x_print_auto_sink: RDO current 500:0 mA
[   82.485347] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO 0 mW 0:0 mV
[   82.492594] tps6598x 0-003f: tps6598x_print_auto_sink: non-battery PDO 2000 mA 0x0

With SNKIntrusiveMode set

[  103.000875] tps6598x 0-003f: tps6598x_print_auto_sink: Fixed PDO
[  103.006904] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO
[  103.013123] tps6598x 0-003f: tps6598x_print_auto_sink: Variable PDO
[  103.019423] tps6598x 0-003f: tps6598x_print_auto_sink: no USB suspend flag
[  103.026322] tps6598x 0-003f: tps6598x_print_auto_sink: give back flag
[  103.032785] tps6598x 0-003f: tps6598x_print_auto_sink: auto compute min sink power
[  103.040378] tps6598x 0-003f: tps6598x_print_auto_sink: highest power
[  103.046763] tps6598x 0-003f: tps6598x_print_auto_sink: min sink power 15250 mW
[  103.054008] tps6598x 0-003f: tps6598x_print_auto_sink: RDO power 0:0 mW
[  103.060653] tps6598x 0-003f: tps6598x_print_auto_sink: RDO current 0:0 mA
[  103.067492] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO 0 mW 0:0 mV
[  103.074772] tps6598x 0-003f: tps6598x_print_auto_sink: non-battery PDO 0 mA 0x0

Hello,

A few initial questions about your system:

1. Can you upload your project file?
2. What version of the GUI are you using? 

Thanks,

Emma

Hi Emma,

I tried uploading the project file and that failed. There is a link to it in the first message.

GUI build version 6.1.1

I've also been digging deeper and even if I set the "0x37 Auto Negotiate Sink" register to sane values the RDO still gets sent with bogus values.

Hello,

Have you been able to reproduce this issue on an EVM? What are you using as your source in this situation? Can you attach logs that have a decoded data column?

Regards,

Emma

Hi Emma

Sorry I don't have an EVM to test with.

I can reproduce this with different sources.

Unfortunately the tool I'm using will only output CSV. The source capabilities has 3 PDOs

1) FIXED 5000mV 3000mA

2) FIXED 9000mV 2000mA

3) FIXED 12000mV 1500mA

The request RDO ( 0x1B00000A ) is for object 1 with an operating current of 0mA and a max current of 100mA

Hi Angus, 

Can you try loading a default 982 project onto your board and seeing if the source and sink can negotiate a good contract? Choose the UFP option and then put in your sink capabilities and see if the two can negotiate. 

Regards,

Emma 

Hi Emma,

Using the same project file but without SNKIntrusiveMode set we the source and sink can negotiate a contract. As soon as SNKIntrusiveMode is set without any other changes the TPS65892 firmware garbles the RDO.

For compatibility with another device SNKIntrusiveMode must be set for us.

Thanks

Angus

Initially I suspected the Auto Negotiate Sink register was incorrectly set but now I print out the register and the dead battery flag on receipt of the source capabilities interrupt. Could it be the device incompatible flag that is confusing the tps65892 firmware ? The protocol analyzer shows that as a PD version 3 message but the tps65892 seems to parse it into the source capabilities register correctly.

[ 2063.315225] tps6598x 0-003f: Received irq event: 0x100000000: 0x1 0x0 status 0x540c0d pwr 0xb pd 0x3c
[ 2063.324471] tps6598x 0-003f: WARN DEVICE_INCOMPATIBLE : 0x100000000 0x0
[ 2063.349338] tps6598x 0-003f: Received irq event: 0x6204000: 0x0 0x6204000 status 0x540c0d pwr 0xb pd 0x3c
[ 2063.370135] tps6598x 0-003f:          far end updated source capabilities: 0x6204000
[ 2063.377300] tps6598x 0-003f: Dead battery flag NOT set.
[ 2063.386280] tps6598x 0-003f: tps6598x_print_auto_sink: Auto sink register 0x30006f 0x2830 0xc864 0x0 0x0
[ 2063.395815] tps6598x 0-003f: tps6598x_print_auto_sink: Fixed PDO
[ 2063.401858] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO
[ 2063.408067] tps6598x 0-003f: tps6598x_print_auto_sink: Variable PDO
[ 2063.414363] tps6598x 0-003f: tps6598x_print_auto_sink: USB comms
[ 2063.420396] tps6598x 0-003f: tps6598x_print_auto_sink: no USB suspend flag
[ 2063.427295] tps6598x 0-003f: tps6598x_print_auto_sink: give back flag
[ 2063.433760] tps6598x 0-003f: tps6598x_print_auto_sink: auto compute min sink power
[ 2063.441376] tps6598x 0-003f: tps6598x_print_auto_sink: highest power
[ 2063.447831] tps6598x 0-003f: tps6598x_print_auto_sink: min sink power 12000 mW
[ 2063.455107] tps6598x 0-003f: tps6598x_print_auto_sink: RDO power 2500:12000 mW
[ 2063.462358] tps6598x 0-003f: tps6598x_print_auto_sink: RDO current 500:1000 mA
[ 2063.469617] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO 0 mW 0:0 mV
[ 2063.476882] tps6598x 0-003f: tps6598x_print_auto_sink: non-battery PDO 3000 mA 0x0
[ 2063.517056] tps6598x 0-003f: Received irq event: 0x1001000: 0x0 0x1001000 status 0x640c0d pwr 0xf pd 0x3c

Here's an easier to read print out of the auto sink register

[   52.914323] tps6598x 0-003f: Received irq event: 0x100000000: 0x1 0x0 status 0x540c0d pwr 0xb pd  
0x3c                                                                                                 
[   52.923649] tps6598x 0-003f: WARN DEVICE_INCOMPATIBLE : 0x100000000 0x0                           
[   52.948469] tps6598x 0-003f: Received irq event: 0x6204000: 0x0 0x6204000 status 0x540c0d pwr 0xb
pd 0x3c                                                                                             
[   52.969158] tps6598x 0-003f:          far end updated source capabilities: 0x6204000              
[   52.976356] tps6598x 0-003f: Dead battery flag NOT set.                                           
[   52.985306] tps6598x 0-003f: tps6598x_print_auto_sink: byte 0 0x6f                                
[   52.991552] tps6598x 0-003f: tps6598x_print_auto_sink: byte 1 0x0                                 
[   52.997680] tps6598x 0-003f: tps6598x_print_auto_sink: byte 2 0x30                                
[   53.003905] tps6598x 0-003f: tps6598x_print_auto_sink: byte 3 0x0                                 
[   53.010036] tps6598x 0-003f: tps6598x_print_auto_sink: byte 4 0x30                                
[   53.016275] tps6598x 0-003f: tps6598x_print_auto_sink: byte 5 0x28                                
[   53.022484] tps6598x 0-003f: tps6598x_print_auto_sink: byte 6 0x0                                 
[   53.028597] tps6598x 0-003f: tps6598x_print_auto_sink: byte 7 0x0                                 
[   53.034704] tps6598x 0-003f: tps6598x_print_auto_sink: byte 8 0x64                                
[   53.040939] tps6598x 0-003f: tps6598x_print_auto_sink: byte 9 0xc8
[   53.047143] tps6598x 0-003f: tps6598x_print_auto_sink: byte 10 0x0
[   53.053354] tps6598x 0-003f: tps6598x_print_auto_sink: byte 11 0x0
[   53.059554] tps6598x 0-003f: tps6598x_print_auto_sink: byte 12 0x0  
[   53.065787] tps6598x 0-003f: tps6598x_print_auto_sink: byte 13 0x0  
[   53.071989] tps6598x 0-003f: tps6598x_print_auto_sink: byte 14 0x0  
[   53.078186] tps6598x 0-003f: tps6598x_print_auto_sink: byte 15 0x0  
[   53.084381] tps6598x 0-003f: tps6598x_print_auto_sink: byte 16 0x2c
[   53.090703] tps6598x 0-003f: tps6598x_print_auto_sink: byte 17 0x1
[   53.096915] tps6598x 0-003f: tps6598x_print_auto_sink: byte 18 0x0  
[   53.103151] tps6598x 0-003f: tps6598x_print_auto_sink: byte 19 0x0  
[   53.109348] tps6598x 0-003f: tps6598x_print_auto_sink: Fixed PDO           
[   53.115396] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO         
[   53.121599] tps6598x 0-003f: tps6598x_print_auto_sink: Variable PDO                
[   53.127880] tps6598x 0-003f: tps6598x_print_auto_sink: USB comms                   
[   53.133913] tps6598x 0-003f: tps6598x_print_auto_sink: no USB suspend flag         
[   53.140838] tps6598x 0-003f: tps6598x_print_auto_sink: give back flag              
[   53.147301] tps6598x 0-003f: tps6598x_print_auto_sink: auto compute min sink power
[   53.154924] tps6598x 0-003f: tps6598x_print_auto_sink: highest power           
[   53.161313] tps6598x 0-003f: tps6598x_print_auto_sink: min sink power 12000 mW     
[   53.168619] tps6598x 0-003f: tps6598x_print_auto_sink: RDO power 2500:12000 mW                   
[   53.175887] tps6598x 0-003f: tps6598x_print_auto_sink: RDO current 500:1000 mA                    
[   53.183190] tps6598x 0-003f: tps6598x_print_auto_sink: Battery PDO 0 mW 0:0 mV                    
[   53.190500] tps6598x 0-003f: tps6598x_print_auto_sink: non-battery PDO 3000 mA 0x0 

Hi Angus, 

I think that the device incompatible flag should not be set here. Can you try a different device to plug in to and see if you are still seeing that flag?

Regards,

Emma

I see a device incompatible interrupt whenever there is a v3 message captured by the protocol analyzer. So yes it does happen with other chargers.

Hi Angus,

The next step should be reproducing this on an EVM. Are you able to get an EVM?

Regards,

Emma

I do not have access to an EVM.

Hi Angus,

I will need to test this on an EVM but will not have access to the lab until next week. I will update you after the thanksgiving holiday. 

Regards,

Emma

Hi Angus,

I am continuing to debug this issue. I have talked with the team about it and it appears to be a persistent issue. We will continue working on it and will update you again soon.

Thanks,

Emma

Thanks Emma

Hi Angus, 

I was able to get an issue update/background today. So first, if you are designing a new system, I suggest moving to the TPS65987D. The TPS65982 is at EOL and is not recommended for new designs. 

That being said, this issue with SNKIntrusiveMode has been persistent because the negotiation relies on the EC for sink negotiation and timings. The PD controller uses its own timings in AutoNegotiateSink which ensures that negotiation can happen correctly and that the sink negotiations are compliant. As we cannot from the PD controller, control how the EC performs negotiations and ensure the proper timing, we cannot guarantee its function. We have removed this feature from our next gen devices, the TPS65987D. 

Thanks,

Emma

This is not a new design so changing the part at this time would not be possible unless the TPS65987D is a pin and software compatible.

According to the TPS65982 documentation the chip will send a negotiation on behalf of the EC if the EC is nearing the timeouts in the standard. We see this response generated by the TPS65892 but it is incorrect and not based on the PDOs received or the settings in the AutoSink register.

Hi Angus,

Apologies, I did not mean to mark the resolved on your post. I can talk with the team more to see if there is anything we can do in this situation, however, this is not a feature we support any longer so I do not know what direction we will end up going with this. 

Thanks,

Emma

Hi Angus,

We are checking internally to see if anything can be done for this issue. This is an older device, and this feature does not exist in newer devices due to compliance challenges. Let's discuss your specific reason for using SnkIntrusiveMode and see if we can come up with an alternative solution using autonegotiatesink. What is your use case?

Thanks,

Emma

Hi Emma,

We were using SnkIntrusiveMode to work around issues with PD power and AUX negotiation in certain devices as it extended the responses. The extended responses would allow PD negotiations to work in some instances but due to it returning the incorrect RDO it would fail with others.

As the tps65892 as not working according to the documentation we found other ways of getting those problematic devices working without the delays.

it would be nice if this feature worked correctly as it would be helpful debugging certain PD negotiations but it is no longer a required use case for us.

Hi Angus,

Thank you for understanding. I am glad to hear that you were able to find work arounds. 

Thanks,

Emma