TUSB8040A1: TUSB8040A1 Over Current Protection

Hi Kawa,

The input is debounced so a short noise event will not trigger an overcurrent.  The hub will continue to report the overcurrent as long as the input is asserted. 

Is there a certain pulse width that is of concern?

Regards,

JMMN

Hi JMMN,

Overcurrent detection with TPS22950 will quit asserting faults when the IC temperature is low.
Faults are asserted for a period about 3ms, which occurs periodically.
In this case, can't the TUSB8040A1 respond by debounce time?
Also, what is the debounce time setting value of TUSB8040A1?

Regards,

I will need to check with design.

Hello Kawa,

Can you check:

• What crystal did they use for the hub? What is it’s start up time?
• Have they confirmed the fault timing from the TPS22950?
• Does neither  part of the hub, 2.0 nor 3.x, report the fault?  Can the customer tell?
• Is the hub configured as ganged or per-port?
• What state is the hub in for this test, unconnected, L0, L1, L2, U0, U1, U2, U3?

Thanks!

JMMN

Hi JMMN,

・What crystal did they use for the hub? What is it’s start up time?
     DSX321G (24.0M)
・Have they confirmed the fault timing from the TPS22950?
      Yes
・Does neither part of the hub, 2.0 nor 3.x, report the fault? Can the customer tell?
      Yes, neither port reports a fault.
・Is the hub configured as ganged or per-port?
      per-port
・What state is the hub in for this test, unconnected, L0, L1, L2, U0, U1, U2, U3?
      L2,U3

In our tests, it was reported to the host with a Low input of about 2.5 seconds or longer.
Is this correct?

Regards,

Hello,

Can you clarify this statement?

Kawa said:

In our tests, it was reported to the host with a Low input of about 2.5 seconds or longer.
Is this correct?

Does that mean that the host has been in L2/U3 for 2.5 seconds?  Or is the OVERCURz asserted low for 2.5 seconds, or another signal?

Regards,

JMMN

Also, can the customer confirm if the crystal starts up when the overcurrent event is asserted?  If so what is the delay between the overcurrent and the crystal start up time?

Hi JMMN,

This is when OVERCURz is asserted low for 2.5 seconds.

Before the overcurrent event is asserted, the crystal has already completed its startup.

Regards,

Hi Kawa,

Earlier you mentioned that the faults were asserted for only 3 ms?  I took this to mean that the OVERCURz is asserted for 3 ms.  That is incorrect?

So if the OVERCURz is asserted for a full 2.5 seconds, does the hub wake up:  does the crystal start?

Regards,

JMMN

Hi JMMN,

Earlier you mentioned that the faults were asserted for only 3 ms? I took this to mean that the OVERCURz is asserted for 3 ms. That is incorrect?
Your understanding is correct.
It will be asserted intermittently as shown in the attached image.

So if the OVERCURz is asserted for a full 2.5 seconds, does the hub wake up: does the crystal start?
After asserting OVERCURz for 2.5 seconds, the hub remains in the U3 state.
Also, the Crystal is running even before asserting.
Does the Crystal not run in the U3 state?

Regards,

Hi Kawa,

Yes, I would expect the crystal to stop running while the hub is in U3/L2.

Can you confirm that the OVERCURz is asserted intermittently for 2.5 seconds - is that correct?  Does the PWRCTL output from the hub toggle too?

Is the USB host in sleep or hibernate (S3/S4)?  What is the state of USB_VBUS?

What is the system behavior at ambient temperature?

Thanks,

JMMN

Hi JMMN,

As shown in the attached image, it is a U3/L2 state, but Crystal is running.

Can you confirm that the OVERCURz is asserted intermittently for 2.5 seconds - is that correct?  Does the PWRCTL output from the hub toggle too?
Yes, OVERCURz is asserted intermittently if the overcurrent condition is maintained.
As shown in the attached image, asserting OVERCURz intermittently is not enough to notify the USB host controller.

Is the USB host in sleep or hibernate (S3/S4)?  What is the state of USB_VBUS?
It is not in sleep or hibernate state.

Regards,

If the TUSB804x has status to report to the host, it will wake from L2/U3.

If the OVERCURz signal is de-asserted, the hub will re-enable the PWRCTL output unless the USB host controller has disabled power.

Typically a USB host controller will disable downstream port power on all the hub ports when a overcurrent event is reported and require a reset to re-enable power.  

Which USB host controller and operating system is being used here?

Regards,

JMMN