TPS65981: Not working as a device

Hi,

We will look into this as soon as possible. Meanwhile, can I know the reason why TPS65981 is used in the design. We do not recommend customer using TPS65921 for new design.

Regards.

The TPS65981 was used because we copied this circuit over from a previous project. 

Hi,

Are you planning on to pass any certification using TPS65981?

Regards.

We do not plan to pass any certification using the TPS65981. If you have any recommendations for a replacement in our future projects that would be appreciated, but we do want to get the TPS65981 functional on our current boards. 

I see. The devices we recommend for customer to use for TPS65981 replacement are TPS25750 (for power only application) and TPS65987D.

I will look into the current issue and get back to you as soon as possible.

Regards

Has there been any progress on determining the problem with our setup?

Hi,

We are still looking into this problem and will get back to you as soon as possible.

Regards.

Hi,

From the configuration file it seems like you are using GUI version 6.1.1. Can you try flashing the TPS65981 again using the latest GUI version 6.1.3 and see if this problem still persist?

Regards

No change in behavior. The only thing that is different is when I use the slightly newer version of the software I get this warning when generating the .bin file. 

Hi,

Thank you for the update. I will consult my team to get a feedback on this issue.

Regards.

Hi,

Below is the input from my colleague on this issue,

"From the trace, it looks like an LPM packet handling issue. I can see Reset from Host after LMP ACK packet, this could be due to incorrect behavior from the devices side during L0->L1 transition. USB2 LPM packets are from the USB controller (not from PD), hence I don't think its PD controller issue."

To confirm this theory, can you try blue wiring USB2 controller DP/DM directly on to the connector side (Use shortest wires possible) like the picture shown below?

Regards.

Directly connecting the USB2.0 signals results in different behavior, but it is still having issues. Windows doesn't throw an error but I can't access the USB storage gadget in Linux and when we connect the AM62xx up to one of our other boards we get the following messages:

oot@imx8x-phycore-kit:~# [ 49.312228] usb 3-1: new high-speed USB device number 2 using ci_hdrc
[ 49.346518] usb-storage 3-1:1.0: USB Mass Storage device detected
[ 49.353027] usb-storage 3-1:1.0: Quirks match for vid 0525 pid a4a5: 10000
[ 49.360055] scsi host0: usb-storage 3-1:1.0
[ 50.532221] usb 3-1: reset high-speed USB device number 2 using ci_hdrc
[ 50.960209] usb 3-1: device not accepting address 2, error -71
[ 51.092232] usb 3-1: reset high-speed USB device number 2 using ci_hdrc
[ 51.520229] usb 3-1: device not accepting address 2, error -71
[ 51.652233] usb 3-1: reset high-speed USB device number 2 using ci_hdrc
[ 51.800218] usb 3-1: device no response, device descriptor read/64, error -71
[ 52.052230] usb 3-1: device no response, device descriptor read/64, error -71
[ 52.292234] usb 3-1: reset high-speed USB device number 2 using ci_hdrc
[ 52.440231] usb 3-1: device no response, device descriptor read/64, error -71
[ 52.692228] usb 3-1: device no response, device descriptor read/64, error -71
[ 52.804356] usb 3-1: USB disconnect, device number 2
[ 52.988241] usb 3-1: new high-speed USB device number 3 using ci_hdrc
[ 53.420226] usb 3-1: device not accepting address 3, error -71
[ 53.552224] usb 3-1: new high-speed USB device number 4 using ci_hdrc
[ 53.984196] usb 3-1: device not accepting address 4, error -71
[ 53.990113] usb usb3-port1: attempt power cycle
[ 55.596225] usb 3-1: new low-speed USB device number 6 using ci_hdrc
[ 55.765245] usb 3-1: No LPM exit latency info found, disabling LPM.
[ 120.006161] usb 3-1: USB disconnect, device number 6
[ 124.068213] usb 3-1: new low-speed USB device number 7 using ci_hdrc
[ 124.236545] usb 3-1: No LPM exit latency info found, disabling LPM.
[ 129.425475] usb 3-1: USB disconnect, device number 7

root@imx8x-phycore-kit:~#

We are also getting a lot of corrupt packets when viewing the communication through the Beagle 

In light of your earlier suggestion of using the TPS65987D as a replacement, we are designing a new circuit using the TPS65987D (though we are still interested in trying to debug the issues with the TPS65981). We want to be able to use USB-C as both a host/device as well as being able to power the system from USB-C. I have attached the new schematic below. If you could look over it for us for any glaring issues with our design that would be greatly appreciated.

Hi,

I think the data corruption could be due to the poor data integrity from blue wiring. However, TPS65981 is a multiplexer and does not handle USB2 packets so I think it has something to do with the USB controller.

I will review the schematic and get back to you.

Regards.

Has there been any further progress on resolving our issue with the TPS65981 or on reviewing our new design for the TPS65987D as we are looking to start production on boards using the new circuit in the next week or two. 

Hi,

I will provide the TPS65987D schematic review by Friday.

Regards.

Hi,

Please see the schematic checklist and the comments in the file below.

TPS65987D_SCH_REVIEW.xlsx

Regards.

Thank you for the review. Has there been any further progress on resolving our issue with the TPS65981? While we are replacing it with the TPS65987D on one of our newer boards, this issue still effects some of our older board designs.