TUSB4020BI: Downstream port(s) become unresponsive

Hi Matthijs,

Does the USB hub still appear connected? It is possible to put the TUSB4020B into programming mode by creating a single ended one condition on one of the downstream ports for a full 1-2 seconds, but in that case the hub would disconnect and reconnect as a Programming Endpoint. Other than that, it could be a case of the Linux driver missing a port change bit and the hub and the host get out of sync. Do you have any visiblity into the USB traffic when this occurs? This is not a known and issue and not something we have duplicated in our lab.

Regards,
JMMN

Thank you for your reply.

Yes, it does still appear connected. Whenever this happens we always check dmesg for the last messages but nothing stands out. So that would mean that the programming mode can be excluded? Also the situation where only one downstream port is unresponsive would exclude this. But maybe we are looking at 2 different things.

Just in case we did not catch the programming mode in dmesg (at out clients we cannot check this, only in the office and its is impossible to reproduce on demand) would the hub automatically switch back after a timeout or would it stay in that state forever? And would there be a way (external components, setting a flag..) to prevent this from ever happening?

Is there a way to easily create this situation with external components, pull up/down the USB lines to external 3v3? Then we can see if this matches the behavior we observe and work backwards from there.

The port change bit and getting out of sync; would this naturally resolve or does this require a (hard) reset?

"Do you have any visibility into the USB traffic when this occurs?" We check in dmesg but other than that we do not have something monitoring the USB traffic. Could we have for example wireshark run in the background and filter for some specific event? Could you point us in the right direction on investigating this angle?

If the hub entered programming mode it would disconnect from USB and reconnect as an entirely different device and would not exit that mode until power cycled. Normal operation should not put the hub into this mode as it requires a SE1 state (illegal in USB 2.0) on a downstream port for 2 full seconds. You can force this state in your lab, by pulling up DP and DM to 3.3V using resistors, but i think we can rule this out as the cause.

Unfortunately the Linux drivers are a little more difficult to debug than Windows drivers. If the host and the hub got out of sync, it could require a reset of the hub to clear it. Can you confirm that downstream port power remains on in the hub when it becomes unresponsive and that an overcurrent condition has not been flagged? Also, when the port becomes unresponsive are you able to try connecting a different speed device (like a mouse) just to verify if the port is running at all?

What does the dmseg look like when a port becomes unresponsive? Is anything reported?

Any update?

"Can you confirm that downstream port power remains on in the hub" we do not use the power from the hub but an internal power supply, I cannot access the power pins of the hub unfortunately.

"confirm ..an overcurrent condition has not been flagged" We do not utilize the over-current pins on the hub but we do detect a over-current situation of the hub as a whole, when the whole hub uses too much current (100mA) it will get reset. I have not seen any message pass by on Linux regarding an over-current situation (dmesg).

"What does the dmseg look like when a port becomes unresponsive? Is anything reported?" As far as I know there is event/error logged.

While we are using the hubs on a daily basis we have not seen any events recently and thus are not able to investigate further the pointers you have provided.

In case it is an over-current situation, would this require a full (hard) reset? Would it therefore be advisable to utilize the over-current pins in order to reset the entire hub?

Hi Matthijs,

Overcurrent events typically require a hard reset of the system or a full USB reset - it depends on what the driver behavior is when an overcurrent is reported. USB protocol allows an overcurrent to be handled using USB reset, but some drivers call for a power on reset before clearing the condition.

The TUSB4020B will disable downstream port power when an overcurrent event is signaling to one of its overcurrent inputs. If overcurrent is reported by another method, the TUSB4020B will not be aware of it. Is this application bus powered? 100 mA is a very low threshold for an overcurrent event.

Regards,
JMMN

The application is self-powered. It is powered from a battery as well as a li-ion charger, they all share a GND.

We are at a clients site where they are have issues every few minutes.

What we notice in the dmesg now is that the hub for some reason pops out ('USB disconnect') then comes back (after 4 seconds) but does not enumerate correctly. (id 80ff instead of 827)

dmesg shows the following;

usb 3-4: USB disconnect,device number 59

usb 3-4: new high-speed USB device number 67 using xhci_hcd

usb 3-4: New USB device found, idVendor=0451, idProduct=80ff

usb 3-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Ah! The hub is going into programming mode. This will happen if the DP/DM lines on a downstream port are pulled high for over 2 seconds. The line state (single ended one) is an illegal line state under normal conditions, so we implemented it as a backdoor to enter programming mode since it should never occur in a standard USB ecosystem.

Regards,
JMMN

Thank you for your fast response!

Would this SE1 have to be at 3.3V level (USB1.1) or will a 0.4V level (USB2.0) trigger the programming mode as well?

Does this even happen while the others downstream port is connected and has (heavy) traffic?

Besides the SE1, I saw that an empty EEPROM would have the same result on power up, we use a EEPROM.. Would there be any other reason where something EEPROM related could trigger this? Since the EEPROM does function since the hub works correctly after power up.

If I understand correctly there is no possibility that something upstream (GND potential difference for example between hub and upstream PC) could trigger this, correct? And no software signal can trigger this either right? What we have observed is that it happens when the hub is connected to a PC but it does not happen when connected to a laptop. Also inserting an extra bus-powered hub in between seems to have an effect on the occurrence.

The SE1 would be at a USB 1.1 level, not HS differential. It would happen regardless of traffic if the DP/DM lines were driven high for over 2 seconds unexpectedly. A blank EEPROM will also force the hub into programming mode, but the hub will only enter the state when it checks the EEPROM after a GRSTz goes high.

The programming driver can be force loaded on the hub, but that would need to be done manually. Does the customer system have the programming driver installed?

Is there any chance that there is a SE1 being driven on the upstream port?

Regards,
JMMN

Any update?

We do not believe it is possible for our system to generate USB1.1 level logic SE1 for 2 seconds, we use HS only. The chip connected to the hub is a FT232H. The EEPROM is not blank since the hub functions properly before and after, having the correct serial number and manufacturer.

We were not able to spend enough time with our customers setup to scope out everything so we will need to fly to them soon for more investigation. Then we will be able to prove whether a downstream SE1 is occurring or not.

We or our customer are not in possession of the programming driver. If we had, would we be able to force it to re-boot though the driver?

An upstream SE1 would not cause the hub into programming more right? The setup at the customer is battery powered inside a van, which is different than normal setups on mains in an office. The upstream of the hub connects to a 6 port PCIe USB card or to the motherboard USB ports. What we did notice is a difference when connecting to a laptop (floating GND) or when connecting a single hub (EX-1113HMS, bus powered) in between the setup and the hub, same GND. So this could only come into play when something upstream could cause the hub into programming mode..

Hi Matthijs,

I need to confirm with design if a SE1 on the upstream port could force the device into programming mode since this is not an expected use case. Please accept my friend request and I can send you the programming driver.

Are you seeing the issue when directly connected to the laptop or with the hub in the middle?

Regards,
JMMN

Based on what we were able to observe a direct connection or a connection thought the extra hub does not show the issue.
So;
device->TI hub[1]->laptop; good
device->TI hub[1 / many]->extra hub->laptop; good (laptop has only 1 port)
device->TI hub[1 / many]->extra hub->customer system; good
device->TI hub[1]->customer system; bad
device->TI hub[many]->customer system; mixed

In case of 'many' just 2 devices were connected to 1 hub, all other (15) hubs did not have any devices downstream

Did you get any confirmation whether any upstream event could cause the hub to go into programming mode?

Hi Matthijs,

I have not gotten an answer from design but I was not able to get the hub into programming mode using a SE1 on the upstream port. Can you check the lines states of the ports prior / during device connection?

Regards,
JMMN

We are planning to fly out to our customer somewhere in the coming days to be able to do further investigation.

In the meant time we have been doing all we can in our office in an attempt to reproduce the issues. Until now we have not been able to get the hub to go into programming mode.

We do however at this moment have 1 downstream port of 1 hub which shows different behavior.

Following is what we have observed; resistance measurements on D+ and D- with plus and minus if the multi meter as indicated. In my experience a proper hub has 33k resistance both ways.

State	+ / -	- / +
Power off	702k	458k
Power on (nothing connected)	20.15k	9.5k
Device connected, then disconnected	20.15k	9.32k
Bulk transfer failed, the node disconnected	0 Ohm	262 Ohm

After a bulk transfer fail we cannot start a new download but simple short commands do arrive and trigger the proper actions (switching LEDs on/off). So the communication does not seem completely down. Can this be an electrical fault in the hub or somehow a state error? dmesg does not show any activity at all when this happens. However, if we remove the device physically dmesg does not show a disconnect and lsusb considers the device even still connected.

Hi Matthjis,

The DP / DM resistance to ground value (or voltage level) is more helpful to us for debug. When the bulk transfer fails it looks like the hub is in single ended zero state (reset), but that doesn't make sense if LEDs on the device are still getting turned off and on.

Which linux drivers are you using?

Regards,
JMMN

State	GND / D-	GND / D+	unit
Power off	64k	490k	Ohm
	0	0	mV
Power on (nothing connected)	750	19.47k	Ohm
	1.3	19.6	mV
Device connected, then disconnected	236	45.6	Ohm
	36.6	2	mV
Bulk transfer failed, then disconnected	235.2	45.7	Ohm
	36.5	2	mV

The resistance of 0 and 260 Ohm as mentioned before is still present.

The driver used by Unbuntu is 'hub', no further information is available on this. The kernel version is; 4.15.0-45-generic [#48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019, x68_64]

HI Matthijs,

I sent you a private message so we can discuss over direct email.

Regards,
JMMN