TPS65981: tps65981: i2c nack and chip restart

Hello Martin,

I'm not sure I fully understand the "storm" of cable connect/disconnects, or the purpose for it, but I'll focus on the NACK.

1. I'm assuming since the TPS65981 is acting as the source that you have a supply going to VIN_3V3. Is there a period of time where voltage is removed from VIN_3V3
2. During the periods of time where our PD controller NACK's, does the voltage on VBUS drop at all?
3. Does your EC ever read register 0x14 (Interrupt register)? If not, I recommend reading this register once the PD controller begins to NACK. See if there are any fault type events (hard reset, over current, etc...)
4. Is the IRQ line triggered before or during the period of time where the PD controller begins to NACK? If so, believe it lines up with item 3

This should be a good starting point for the NACK. Let me know what you're able to find.

Hello Adam,

> I'm not sure I fully understand the "storm" of cable connect/disconnects, or the purpose for it, but I'll focus on the NACK.

The purpose was to trigger this error. We have seen some cases in the logs during normal USB-C usage as well and this was what I came up with. Hopefully it is the same error.

What I do is to use a "USB Type C to USB 2.0 Standard A cable". That cable has a pull-up of CC1 to the VBUS which is 5V on the USB 2.0 host.

I simulate cable disconnect/connect by switching the 5V off/on on the USB 2.0 host side.

> I'm assuming since the TPS65981 is acting as the source that you have a supply going to VIN_3V3. Is there a period of time where voltage is removed from VIN_3V3

The VIN_3V3 is supplied from our system and present all the time.

> During the periods of time where our PD controller NACK's, does the voltage on VBUS drop at all?

Well, yes since I toggle the 5V from the connected USB 2.0 host. So the the tps65981 is experiencing a lot of cable connect/disconnect.

> Does your EC ever read register 0x14 (Interrupt register)? If not, I recommend reading this register once the PD controller begins to NACK. See if there are any fault type events (hard reset, over current, etc...)

> Is the IRQ line triggered before or during the period of time where the PD controller begins to NACK? If so, believe it lines up with item 3

I have made an attachment which shows a logging of what happens during this error.

In the attachment I show a log where I constantly polls registers 0x14 and 0x16 during cable connect/disconnect.

After a while the tps65981 returns the same value in 0x14 for around 3s. After that a short period of zero from the registers, then i2c NACK.

Then running again but with the default value in 0x16 as given by the firmware.

Regards, 

Martin

tps65981_2603202_poll_irq_cable_connect_disconnect.txt

Hi Martin,

Okay I think I understand what is going on now.

Is your TPS65981 configured to act as a power sink? Based on my understanding of your system use case (power source and supports display-port alternate mode sink). In my mind a system cable of being a power source and data sink is a docking application, and you would not expect to connect a source to another source.

With that being said, if your configuration is setup to where the TPS65981 can act as a sink, I would recommend using an oscilloscope to measure the voltage on VBUS, the system side of the sink path for the 5V sink contract, and a current probe to measure the current going back into the system. See if there is a current/voltage spike during the cable disconnect.

Hi Adam,

> Is your TPS65981 configured to act as a power sink? Based on my understanding of your system use case (power source and supports display-port alternate mode sink). In my mind a system cable of being a power source and data sink is a docking application, and you would not expect to connect a source to another source.

Yes you are right, our main use case is as a power-source and as display-port alternate mode sink.

We can source 20 V (via pp_ext), 15V/9V (via pp_hv) and 5V (via pp_5v0).

We do also present a USB2.0 device (a webcam) from which you can stream video.

However, in this case I connect/disconnect a "USB Type C to USB 2.0 Standard A cable"

Type-C-to-USB-2.0.pdf

The VBUS from a USB-2.0 source will always be 5V.

To get this to work I must configure Register 0x28: (System Configuration) to:

PortInfo : 101b Source/Sink. Power Role = Source. Data Role = DFP. PR_Swap supported. DR_Swap supported

State of cc pins (no pd communication)

C_CCn Pin State (0x69)
TypeCPortState : SNK: Attached.SNK (0x22)
CC2PinState : Not connected (0x00)
CC1PinState : 3.0A Advertisement detected (Sink Only) (0x05)
CCpinForPD : C_CC1 is CC pin for PD communication (0x01)

Now there is no pd communication, and we are connected as a USB2.0 sink.

Q1: Will the 5V power-path (pp_5v0) be enabled in this case ?

Even it should be the case it wouldn't make any harm. There is a 5V on that side already from our power-supply and any slight differences in 5V will only cause a minor current to flow.

> I would recommend using an oscilloscope to measure the voltage on VBUS

I will try to provide a plot with measurement from the VBUS. And other measurements. Due to the work situation it may take some time

With reference to my attachment in my previous post (Mar 26)

Q2: What would you say the tps65981 is doing between the timestamps marked with Step 1, 2 and 3 ?

Regards, 
Martin

Hi Adam,

>Believe changing register 0x28 to allow configuration as a legacy sink should fix the issue.

I assume you mean the Portinfo part (2:0) ?

Considering that we must support the use-cases described above: Docking station but also allow for legacy-sink.

What should we set as PortInfo ? Currently we set 0x05.

I have now re-run the test-case described in my post from Mars 26.
Connect and disconnect while polling registers in the tps65981. Now I also read register 0x03 (Mode register).

Now you can clearly see in the sequence that the chip-mode goes from APP -> BOOT -> APP. Ie. a reboot.

tps65981_01042020_poll_irq_cable_connect_disconnect.txt

I think this reboot has nothing to do with the actual source/sink mode. We have seen cases of this also when the user connects a lap-top (we are a docking station).

I used the legacy-sink mode since I was able to reproduce.

Most people maybe use the tps65981 as a "standalone" and not so much setup via i2c. If the chip in some rare cases do re-boot nobody notices. It will come up again and setup the GPIOs and power-delivery.

I think this is a bug in the tps65981 which under very quick connect/disconnect conditions crashes and reboot.

It should be possible for you to try to re-create.

Regards,

Martin