TDA4VM-Q1: TDA4VM-Q1 USB1 to be a slave role with Hub, could be USB Dp/Dn both high in idle state?

Hi,

Our Expert is on vacation.
Will check internally and get back to you.

Best Regards,
Sudheer

Hi, Sudheer

When will TI update about this question?

Hi,

I have Informed to H/W IP Owner to check this, will get response soon.

Best Regards,
Sudheer

Thanks.

Please confirm USB idle state, J & K pattern video of Hub bus power & self power.

Hub self power and USB idle state Dp high,Dn low video.

*Hub bus power and USB idle state Dp/Dn both high. *Finally Dp/Dn drive to low issue happen.

Hi, Shreyas

Cloud is my customer, I think we can combine this thread for discussion, because we are talking the same problems, and try to find "walk around solutions".

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1321589/tda4vm-q1-how-to-software-restart-usb-controller-for-usb0-usb1/5040857?tisearch=e2e-sitesearch&keymatch=%2520user%253A533255#5040857

I guess TDA4 USB1 does not detect USB HOST "detached"  "correctly", and this should be the "root cause", so the problem caused USB1 attach fail for next time (illegal condition). I found something strange in video, capture picture as below.

We can observer VBUS drop down about 0.4 sec, and data line still keep in "J state" (D+ pull high, D- pull low) before device "real detached". I think it should be some conflict in USB line state. I think data line should be in SE0 state first, and then cut off VBUS for USB detached.

Ref. https://en.wikipedia.org/wiki/USB_communications

Update my opinion, and need suggestion, need help : 

(1) Need USB software reset way for walk around testing.

(2) Do we have USB device "detached / attach" example with VBUS always 5V?

(3) How do we detect USB1 error happens?

Many Thanks

Gibbs

Hi,Shreyas 

Can TDA4 disable SE1(Dp/Dn high) illegal condition judgement?

After illegal condition, avoiding Dp/Dn were drove to constant low.

In other hand when illegal condition happen then Dp/Dn were drove to low, does it meet TDA4 USB design status expectly?

Hi Gibbs

Because no USB error detection that we just suppose Dn high is root cause by below some tests.

1-VBUS_USB1 keeps constant 5V in Hub 5V power trace without drop happen. But MDD fail still happen again. So VBUS item may not issue cause. Strangely USB bus will lock Dp high & Dn low without data communication. It seems new fail case different to original Dp/Dn low issue.

 2-Changing Hub to self-power in correct USB2.0 idle state Dp high/Dn low(SE0), issue not happen any more.

*So Dn/Dp both high illegal condition maybe issue root cause.

Hi, Gibbs & Shreyas

Please confirm de-attach waveform(Hub's VBUS off & Dp PU in short time), it seems really impact to TDA4 USB1 idle status.

What's your suggestion about this problem?

Hi, Cloud

Follow your description,

I feel a little bit confuse about this part : 

"2-Changing Hub to self-power in correct USB2.0 idle state Dp high/Dn low, issue not happen any more."

Does it mean problems solved when you set Hub in self-power?

Gibbs

Hi Gibbs:

Yes, but customer's Hub was mass product in industrial market for several years.

I really don't know why Hub resets VBUS/Dp/Dn after host unplugged from upstream port...

Hub maybe originally applicate for only OTG device...

So far we could converge TDA4’s USB controller crash in hub’s first reset period.

Next speculation and proof Dp/Dn both high were pulled up by Hub’s second reset period.   

As per our discussion, 'the Hub changed to self-powered, and the issue does not happen anymore indicating that the Vbus is always enabled with the self-powered Hub, however, the Vbus logic is not being detected correctly by the hub when its not self-powered. It indicates that the Hub may have the likely issue to be fixed to get this working.

Hi Shreyas

Self-power will always keeps host OTG 5V in upstream port(Hub circuit design). So Hub will not repeatedly execute to reset VBUS1/Dp/Dn in downstream port during host disconnet.

Yesterday I had shared some benchmark tests to Gibbs. Please discuss with him.

Thanks.

Yes, that is the issue where the Hub in self-powered mode always keeps the Vbus on; whereas in normal operation, the host must implement the Vbus reset, and detect the connect/disconnect of the USB device which is not happening in this case. So, probably the Hub's internal logic must be looked into.