TUSB2046B: Powercycling order needed?

Hi Franz,

How are the downstream ports being reset / power cycled?   Typically a USB host will either send a USB reset to the entire bus or do a port power off / on command to all the TUSB2046B ports.  Do they have a custom utility that is generating the USB commands?

Regards,

JMMN

Hi JMMN,

I used a port power off/on command via uhubctl. If I reset the whole hub it works properly.

Regards,

Daniel

Hi Daniel,

What order do you have to reset the hub ports in order for it to work?

None of the ports are set up as ganged (shared power for the downstream ports), correct?

Regards,

JMMN

Hi JMMN,

assuming that port 2 and 4 are affected by an ESD event I tryed to reset port 2 (reset worked, PWRON was toggled, still no USB communication). Then I resetted port 4 which worked (communication was back on). I then resetted port 2 again which worked now (communication was back on). This speaks for the fact that the order seems to be importand. What speaks against this hypothesis is that it also works when all 4 ports are resetted at once. Ports are not set up as ganged.

Regards,

Daniel

Hi Daniel,

If you reset Port 4 first and then Port 2, does that work?  I'm wondering if the original Port 2 reset isn't functional because there is still an error on Port 4.

Also, how is the port not working?  Port power is on but there is no communication?

Do you have any visibility into what happens on the DP/DM lines after the port power is turned back on?  There are quite a few commands that need to get sent before the downstream device is re-enumerated (example below)

Regards,

JMMN

Hi JMMN,

JMMN said:

If you reset Port 4 first and then Port 2, does that work?  I'm wondering if the original Port 2 reset isn't functional because there is still an error on Port 4.

Yes as i described thats exat the behavior I´ve got here. I also thought about the possibillity that internal logic is messed up and resetting the ports therefore doesn´t work properly.

JMMN said:

Also, how is the port not working?  Port power is on but there is no communication?

Exact. But I´ll further investigate to provide more information.

JMMN said:

Do you have any visibility into what happens on the DP/DM lines after the port power is turned back on?  There are quite a few commands that need to get sent before the downstream device is re-enumerated (example below)

I´ll try to further investigate on here and try to provide some scope shots. Basically I think our host system sends the correct commands (in normal operation) because resetting and re-enumerating the device works properly without an ESD event.

Regards

Daniel

Hi Daniel,

Sorry, my question wasn't very clear.  I'm trying to determine if the problem is that both ports need to be reset in any order for them both to work or not.  My guess is that the uhubctl isn't sending all the commands necessary to re-enable the ports until both of the failed ports are reset.

1. Reset Port 4, then Port 2 - works

2. Reset Port 2, then Port 4 - works?

3. Reset just Port 2 - doesn't work

4. Reset just Port 4 - doesn't work?

Regards,

JMMN

Hi JMMN,

I´m not really sure if this is the problem.

JMMN said:

1. Reset Port 4, then Port 2 - works

Correct, works. Both ports are resetted.

JMMN said:

2. Reset Port 2, then Port 4 - works?

Only Port 4 is then resetted, port 2 still doesn´t work.

JMMN said:

3. Reset just Port 2 - doesn't work

Correct, port 2 doesn´t work.

JMMN said:

4. Reset just Port 4 - doesn't work?

Yes, Works properly.

To me it seems that everytime port 4 is involved and needs to be resetted first. Furthermore the problem not only refers to port 2 also port 3 is affected sometimes. Port 1 was never affected but the topology is a bit diffrent. Port 2 to 4 are routed via a galvanic insulator IC to the downstream device. Port 1 is directly connected to the hub. I thought I could exclude the galvanic insulator because it is also resetted with the PWRON signal. Maybe I need to jumper the galvanic isolator IC to be really sure it is not causing the problem.

Regaards

Daniel

Hi Daniel,

Functionally the hub doesn't care what order the ports are reset in and if this was done by typical USB host software, they tend to always reset ports from lowest to highest.  I'm thinking that there could be some command that is getting sent along with the Port 4 reset that doesn't occur with the other Port resets.  Can you get any kind of debug log at that level?  If you are running Linux, usbmon might give enough granularity to figure out if this is a protocol level issue.

Regards,

JMMN

Hi JMMN,

JMMN said:

Functionally the hub doesn't care what order the ports are reset in and if this was done by typical USB host software, they tend to always reset ports from lowest to highest.  I'm thinking that there could be some command that is getting sent along with the Port 4 reset that doesn't occur with the other Port resets

I agree, but if I send the command that all 4 ports shall be resetted at once (uhubctl -p1,2,3,4 ...) it also works proberbly. This would be the "wrong" order because port 4 would be resetted after port 2.

I´m in contact with my colleagues from the SW department to further debug on the protocol level.

Regards

Daniel