TUSB320LAI: USB-C compatibility issue with some laptops when interfacing with TUSB320

can we look at your schematic?

Of course, can you provide your email to me so I can send it over?

Thanks,
Jeff

Hi Jeff,

A quick check would be to ensure Vbus is going high when you expect the device to connect. Do you have a USB-C protocol analyzer to investigate what is happening on the USB bus? 

Hi Malik,

Yes, the laptop was able to provide power to my device even though it wasn't able to recognize it as a USB device (5V, 500-700mA). Attached is the log file I captured using a USB-C protocol analyzer (10 connections to M1 MacBook with 0 success recognizing my USB device)

Macbook M1 unable to recongize USB.xlsx

This is the register readout of the TUSB320 for the same 10 unsuccessful attempts. 

tusb_reg_1606776326.csv

Hi Jeffery,

It seems that TUSB320LAI is seeing a connection sometimes based on the 0x09 0x08 register. Is this a USB 2 or USB 3 application? Is the INTERRUPT_STATUS bit being cleared by SW? SW must make sure the INTERRUPT_STATUS has been cleared to zero. Rewrites to this register are needed for the INT_N to be correctly asserted for all interrupt events.

The log file only shows PD messages but TUSB302LAI does not communicate over PD messaging. We should be looking for RD/RP status during the initial connection.  

Hi Malik,

- Yes, looks like TUSB320LAI was able to detect everytime when connection is made.

- We are using this for USB2.0 application. 

- Yes, INTERRUPT_STATUS bit is being cleared by SW. The log only records when INTERRUPT_STATUS bit is high.

- Our analyzer only records PD massages. Should I look at the RD/RP status using a logic analyzer or is there a USB-C protocol analyzer you could recommend?

Thanks,

Jeff

Hi Malik, 

I just found out that INTERRUPT_STATUS bit is NOT being cleared by our current SW. We will make that change and test. Can you explain how could that potentially cause an issue?

Thanks,
Jeff

Hi Jeff,

A simpler and effective solution is to simply probed the CC line with a high impedance probe. All CC logic is done by TUSB320 before PD messaging starts. If the INTERRUPT_STATUS is not cleared it can prevent the INT_N pin from being correctly asserted for all interrupt events.

Hi Malik,

We have fixed the SW to clear interrupt_status after each interrupt event. The results were pretty much the same as before. Attached is the log of the TUSB320 register 0x08, 0x09 and 0x0A. The first 10 connections were directly plugged into a HP Elitebook 850 notebook USB-C port. The laptop failed to recognize our USB device each time. The next 10 connections were connected to the same laptop thru a USB-C hub. The laptop was able to recognize our USB device each time. 

I will try to capture the CC lines activity for you next. 

Thanks,

Jeff tusb_reg_1608741689.csv

pls accept my friendsheip request and send schematic with private message

Ok. Friendship accepted and the schematic was sent privately.

Thanks,

Jeff

schematic looks fine. Is this DRP? what problem you have, DFP or UFP?

Yes, our product is set to DRP by default. However, there are times we would change the mode to UFP depends on the use case. The issue is when our product is connected to certain laptops, it couldn't be recognized as a USB device even though we already configured it as an UFP.

It only works (recognize by certain laptops) when we use a USB-C hub or use a USB-C to USB-A cable (which bypass the TUSB320 CC lines)

Can you probe MCU_Pwr and USB_Vbus, CC1, CC2?

Hi Brian, 

Please see the attached pictures:

Channel 1: MCU_PWR, Channel 2: USB_VBUS, Channel 3: CC1, Channel 4: CC2

1)  When cable is not connected

2) When the cable connection was just made

3) After the cable was connected for a few seconds

normally Type-C should not affect USb2 communication, I saw there are two USB2 lanes going though an USb2 MUX. which lane has issue, hwo to control the Vbus of these two lanes?

We don't see this issue when we used a USB-C to USB-A cable or when we connect our device via a USB-C hub, this is why we believe it would have something to do with the CC configuration controller. 

There are two USB2 lanes going through an USB2 MUX, the first pair goes to battery charger IC (BQ25890) and the second pair goes to the SOC. The control of the mux comes from the DSEL pin of BQ25890.

"DSEL: Open-drain D+/D- multiplexer selection output. Connect the DSEL to a logic rail via 10-KΩ resistor. The pin is normally float and pull-up by external resistor. During Input Source Type Detection , the pin drives low to indicate the bq25890 D+/D- detection is in progress and needs to take control of D+, D- signals. When detection is completed, the pin keeps low when MaxCharge™ adapter is detected. The pin returns to float and pulls high by external resistor when other input source type is detected."

However, when our device is configured as UFP, we would disable MaxCharge so DSEL will always stay high. This basically allows USB signals to go directly to the SOC instead of going to the battery IC first. 

is SOC an OTG device? For UFP, how is vbus connected to SOC, same as USB_Vbus?

Yes, there are some use cases that our product could be configured as an OTG device. 

VBUS is connected to the Battery charger IC- BQ25890 and the output of it (Vsys) provides power for PMIC, then to SOC. 

Below is how USB_VBUS is connected to our SOC for VBUS detection:

Hi Brian, 

Can you provide feedback on the signal waveforms I provided per your request? Do they look normal to you?

Thanks,

Jeff

waveform looks ok.

so the HP type-c port is DRP as well?

Yes, the HP type-c ports are DRP. 

Here is the spec for the HP Type-C port:

- USB 3.1 Type-C® with Thunderbolt™ support

move discussion to email