TPS25750: Cannot act as a source after dead battery flag is cleared

Hi Jeff, 

Jeff LaBundy said:

[1] I find that the device cannot act as a source following a dead battery condition. After the device starts in dead-battery mode and a patch bundle is applied, the registers are read as follows:

Jeff LaBundy said:

Now, both ConnState and PlugPresent are set as expected, and the device behaves normally. Is this behavior expected, and is there any way I can rectify it?

Do you have an I2C scope capture of the EC -> PD traffic starting from the patch bundle process to the end? 

Jeff LaBundy said:

[2] Is there any harm in writing the DBfg 4CC command if the dead battery flag is not set?

There is no harm to sending DBfg even if the dead battery flag is not set, the command should be rejected. 

Thanks and Regards,

Raymond Lin

Hi Raymond—thank you for your prompt support. In response to your feedback:

[1] Sure thing; I have attached the entire capture here. Please let me know in case anything is amiss.

Both source and sink configurations work perfectly fine if the patch bundle is applied after the device boots while powered externally from VIN_3V3. However, only sink configurations work after the following sequence:

• Device boots in dead battery mode.
• External VIN_3V3 supply appears.
• Patch bundle is applied.
• DBfc 4CC command is sent.

To recover, I must send the GAID 4CC command, thereby forcing the device to boot while powered externally from VIN_3V3 as in the passing case. After I re-apply the patch bundle, both source and sink configurations work perfectly fine again.

[2] Thank you for confirming; your description matches my observation.

In case I can provide any additional information in the meantime, please let me know.

Hi Raymond—please forgive my ignorance, but my original attempt to attach a Saleae capture seems to have failed. I have tried again with the capture embedded in a .zip file; please let me know in case it does not appear.
TPS25750_patch_bundle.zip

Hi Jeff,

Due to the holiday, many device experts are currently out of the office. When they return they will look into this and provide a response. Please expect some delay accordingly.

Thanks,
Field

Hi there—just wanted to follow up on this problem. Thanks again for your continued support!

Hi Kevin—many thanks for your comprehensive analysis.

I sent the SSrC 4CC command (PD Send Source Capabilities) in the dead battery state, but the IC responded with 0x03 (task rejected) in the first byte of the payload. Register 0x1A remained unchanged as well.

However, I don't think this or the SWSr 4CC commands would work for our purposes—since the IC does not update register 0x1A unless the dead battery flag was never set, our platform has no way of knowing when to send these commands.

Maybe I can ask a couple questions in the meantime:

1. Since my patch bundle application process appears to be correct, is there any other problem on my side that could explain this issue?
2. As a sanity test, may I ask you to confirm whether you can independently reproduce this problem? I do have a TPS25750EVM at my disposal, and even though I think the online configuration GUI is an excellent tool, it does not allow the customer to freely read registers or send 4CC commands. Perhaps you have your own EC for internal testing.

This problem is ultimately not a blocking issue, because the GAID command appears to be a reliable workaround—since the behavior is unexpected however, I prefer to root-cause it first. Thanks again for your continued support and in case I can provide any additional information, please let me know.

Hi there—this issue seems to be solved now. After further study, I found the problem described in this thread occurs only if the USB sink is connected before the DBfg 4CC command is sent and the dead battery flag is cleared.

If the DBfg 4CC command is sent before the USB sink is connected, the problem does not occur, and register 0x1A is updated normally. In practice, we check the dead battery flag immediately upon start-up, or after the application of a patch bundle; therefore, this problem won't appear during normal use.

Before closing this thread, however, I wanted to highlight a few additional phenomenon and ask one last question:

[1] The DBfg 4CC command can only be sent during APP mode; it is rejected (response = 0x03) if sent during PTCH mode. This seems to have been confirmed in another thread, but I don't see it mentioned in the technical reference manual (TRM); I think this information is useful to include in the TRM.

[2] If VIN_3V3 is lost and the device falls back to dead battery mode, there is no guarantee that it has been reset to the point that it falls back into PTCH mode from APP mode. On our platform, the dead battery flag can be set following recovery from a dead-battery scenario, but also after our platform reboots while USB remains connected. This happens because the VIN_3V3 supply is temporarily disabled and re-enabled during reboot on select revisions of hardware.

In the latter case, I find the dead battery flag is set 100% of the time, but the device remains in APP mode only ~50% of the time. I suspect this is simply a result of different functional blocks inside the IC being placed into reset at different thresholds. This seems innocuous, but does underscore the importance of checking the MODE register along with the dead battery flag prior to sending the DBfg 4CC command as per [1].

[3] In some cases, sending the DBfg 4CC command causes the device to NAK I2C communication for hundreds of ms, similar to the device having been reset in response to the GAID 4CC command. After this period, the command is accepted (response = 0x00) and the device functions normally as both a source and sink.

This phenomenon never seems to occur if the device enters dead battery mode while connected to a PC USB port using a USB-A to USB-C cable. In that case, the registers appear as follows after the DBfg 4CC command is sent:

0x0d: 0xf8 0x19 0x00 0x00
0x0f: 0x61 0x05 0x09 0xf5
0x14: 0x0a 0x00 0x00 0x4d 0x00 0x00 0x00 0x00 0x00 0x00 0x03
0x16: 0x0a 0x30 0x30 0x4d 0x00 0x00 0x00 0x00 0x00 0x00 0x03
0x18: 0x0a 0x00 0x00 0x4d 0x00 0x00 0x00 0x00 0x00 0x00 0x03
0x1a: 0x0d 0x00 0x10 0x40 0x00
0x26: 0x00 0x30 0x00 0x00 0x40
0x29: 0x72 0x50 0x81 0x03
0x2d: 0x30 0x03 0xf0 0xc2 0xa1
0x30: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000
0x31: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000
0x32: 0x01 0xa8 0x2a 0x2c 0x91 0x01 0x26 0x2c 0xd1 0x02 0x00 0x2c 0xb1 0x04 0x00 0x2c 0x41 0x06 0x00 0x00 0x00 0x00 0x00 0x00 0x000
0x33: 0x02 0x2c 0x91 0x01 0x10 0x2c 0xd1 0x02 0x00 0x2c 0xb1 0x04 0x00 0xf4 0x41 0x06 0x00 0x45 0x41 0x06 0x00 0x00 0x00 0x00 0x000
0x34: 0x00 0x00 0x00 0x00 0x00 0x00
0x35: 0x00 0x00 0x00 0x00
0x3f: 0x03 0x02
0x40: 0x04 0x00 0x09 0x00
0x69: 0x01 0x03 0x00 0x61
0x70: 0x01
0x72: 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00

This phenomenon sometimes occurs if the device enters dead battery mode while connected to a USB PD charger using a USB-C to USB-C cable. In that case, the registers appear as follows after the DBfg 4CC command is sent:

0x0d: 0xf8 0x19 0x00 0x00
0x0f: 0x61 0x05 0x09 0xf5
0x14: 0x08 0x10 0x20 0x45 0x00 0x00 0x00 0x00 0x00 0x00 0x03
0x16: 0x0a 0x30 0x30 0x4d 0x00 0x00 0x00 0x00 0x00 0x00 0x03
0x18: 0x08 0x10 0x20 0x45 0x00 0x00 0x00 0x00 0x00 0x00 0x03
0x1a: 0x1d 0x00 0x60 0x40 0x00
0x26: 0x00 0x30 0x00 0x00 0x40
0x29: 0x72 0x50 0x81 0x03
0x2d: 0x30 0x03 0xf0 0xc2 0xa1
0x30: 0x06 0x2c 0x91 0x01 0x08 0x2c 0xd1 0x02 0x00 0xfa 0xc0 0x03 0x00 0xc8 0xb0 0x04 0x00 0x96 0x40 0x06 0x00 0x3c 0x21 0xdc 0xc00
0x31: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000
0x32: 0x01 0xa8 0x2a 0x2c 0x91 0x01 0x26 0x2c 0xd1 0x02 0x00 0x2c 0xb1 0x04 0x00 0x2c 0x41 0x06 0x00 0x00 0x00 0x00 0x00 0x00 0x000
0x33: 0x02 0x2c 0x91 0x01 0x10 0x2c 0xd1 0x02 0x00 0x2c 0xb1 0x04 0x00 0xf4 0x41 0x06 0x00 0x45 0x41 0x06 0x00 0x00 0x00 0x00 0x000
0x34: 0x2c 0xd1 0x02 0x00 0x80 0x00
0x35: 0x2c 0xb1 0x04 0x23
0x3f: 0x0f 0x02
0x40: 0x0c 0x00 0x00 0x00
0x69: 0x02 0x00 0x05 0x61
0x70: 0x01
0x72: 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00

The TRM mentions that the device undergoes a hard reset in response to the dead battery flag being reset, but the conditions are unclear. If the device is indeed being reset, why does it remain in APP mode and function normally?

Thank you in advanced for your support and in case I can clarify any of my observations, please let me know.

Hi there—just want to check in with regard to my question [3]. In case I can clarify any of my observations, please let me know.

Hi Jeff,

Apologies as I missed this thread!

Is question 3 still open?

Thank you,

Kevin

Hi Kevin—thank you for reaching out; yes, it is still open. However, it is not blocking any progress.