TUSB9261: USB repetitive RESET Burst during boot after Super Speed negotiation

Hi Frédéric,

There was a similar issue with multiple resets caused due to power sag on VBUS that could be related.  Do you think this could be the case here?
(6) TUSB9261DEMO: Keeps resetting when connected to SATA SSD - Interface forum - Interface - TI E2E support forums

Regards,

Nicholaus

Hello Nicholaus,

Thank you for your advices,nice finding, 

this acceditate the hypothesis we have concerning the Vbus :  our current design seems suspicious with a Vbus signal provided to Bridge and SoC using a zener +5.1Vvoltage derivated from a local +12V line. this 5.1V is then divided by resitors 40.2k 10K. 

We let you informed of our finding and results of a Vbus signal modification to see if it solves the USB Bus Reset events

Thanks again

Best Regards

Frederic

There is a more detailed specification of Vbus signal Input in version -Q1  (automotive qualified) of  TUSB9261

compared to basic TUSB9261 spec in which one could think it is 5V ( if you did not read the VBUS pad voltage  limitation to 1.155V)

Does -Q1 version description of VBus could be retained as  complementary information for  standard version ?

Best regards

Fred

Hi Fred,

Good question.  After reviewing, they do have the same USB_VBUS spec and are complementary to each other.  The maximum rating is missing from the TUSB9261 datasheet.

TUSB9261
Max Ratings - Not Listed (1.2V)
Recommended - 1.155V
Design requirements - 90.9kohm (1%) and 10kohm (1%) voltage divider

TUSB9261-Q1
Max Ratings - 1.2V
Recommended - 1.155V
Design requirements - 90.9kohm (1%) and 10kohm (1%) voltage divider

Regards,

Nicholaus

Hi Nicholaus,

thanks for this precision, we are now cleaner with the limits for reviewing the design.

But on thing seems still missing to determine the margin we have toward the VBUS loss detection is the threshold level of this monitoring input.

As is seems to be a 1.2V CMOS input shall we consider a trip point at  0.6V   or lower ?

it stays a mystery , and with  Design requirements recommanding a 90.9k/10K divider , for a nominal 5V VBUS this lead to present to VBUS monitoring input 

a voltage of 5 x 10/(90.9+10) = 0.495 V  which shall be above the treshold level of VBUS monitoring with a little marging for noise robustness  and this doesn't match with the 0.6V hypothesis .

Have you access to more data concerning the input characteristics of the VBUS monitoring input to design a robust interface.

Thanks for your support.

Best regards

Fred

Hi Fred,

I'm sorry I can't find this threshold information for the TUSB9261 yet, but I will keep looking.

In your case the acceptable range of Vbus values from the USB spec are: 
Min: 4.4V 
Max: 5.5V

Is the system within spec during the power sag?  If not, then it should be corrected to be USB-compliant. 

The required voltage divider will create the min/max voltages for TUSB9261 VBUS input.  I imagine they will trip around these values with some margin:
Min: 0.436V
Max: 0.545V

Regards,

Nicholaus

OK, Thank you for theses informations.

We are still spying Vbus.

up to now we have only  found a lonely glitch on VBUS just 8ms after USB VBUS activation ( commanded by Keystone), as depicted on the screen hardcopy hereafter, but nothing that seems sufficent to induce a repetitive USB Bus Reset over a large period of time.

our investigations will be pushed forward: we wander now if the keystone itself could not Reset the USB bus from his own side, as his USB interface also monitors the VBUS voltage ( directly from the 5V USB VBUS without divider) on a dedicated analog input .

There are some register dedicated to adjust the voltage level for the VBUS valid threshold.

in SPRUHJ7A–April 2014–Revised August 2017 page157
USB Registers

But there is no detail of how is encoded the adjustement  by steps of +/-1,5% into the 3 bits format, neither the nominal Voltage ( presumed to be 5.00V)

we have the following values after the OS initialisation:

• USB_PHY_CTL2 = 0x2C28CDC4

=> PHY_PC_OTGTUNE = 100b

=> PHY_PC_COMPDISTUNE = 100b

same untouched default values as after a reset

other register allow to select the external VBUS valid source

• USB_PHY_CTL4 = 0xA9F0C000

=> PHY_OTG_VBUSVLDEXTSEL = 0

=> PHY_OTG_OTGDISABLE = 1

same untouched default values as after a reset

But this tricky set up needs more investigations to be understand, and probably only a TI USB specialist could help us to understand it.

Best Regards

Fred

Yes, it might be best to ask a separate question about the KeyStone II architecture.  I have no experience with it, but if you have a USB protocol analyzer it would be useful to capture a trace between the TUSB9261 and host.

However, I can help you with anything regarding the TUSB9261.

Although the power sag is a one-time event, it seems like the previous E2E post I referenced had the same symptom:

"When the industrial SSD is connected, the TUSB9261DEMO seems to be resetting periodically, about every second or so, appearing and disappearing in the Windows device manager."

This is so similar that I think we should ensure this 8ms glitch isn't the root cause.  Do you have one of our TUSB9261DEMO boards to test?  Alternatively, is there anything you can do to remove the glitch?

Regards,

Nicholaus

Hi Frederic,

Any more questions here?  If not I will close the issue.

Regards,

Nicholaus

Hello Nicholaus,

We succeeded to  remove the VUSB glitch by enabling the VBUS power earlyer after SoC ready after power on and bypassing the SoC command which induced the VBUS glitch, but the repetivive USB bus reset remains for some power on sequences.

We just received our new Total Phase Beagle USB 5000 USB3.0 Analyzer.

Investigations will resume to try to identfy on USB protocole which actor from Host (Soc) or device (Bridge) is originating the Reset Commands burst.

Instrumentation is not so easy as we are connectorless between actors , as Soc,Bridge,SSD are linked by trace only on a single PCB. We have to intercept signals between Soc and Bridge and send them through the USB Protocole analyzer. Hope we will not be exposed to signal integrity problem on the SS link  doing so..

So we are not at the end...

Hi Frederic,

Alright I will mark this issue as "waiting for customer".  Let me know if you have any questions.

Regards,

Nicholaus