TUSB2E221: Qualcomm +TUSB2E2211 + GL852GT USB2 hub issue discussion

Hi Kai, Ken,

Looking at the waveforms provided, I don't see why the Port Configuration or XeSE1 is being ruled out. Going by the auto-resume process, there should be no reason for the repeater to be prompted to reset. Where that blue pulse is, I would expect to see SOResume instead of a reset. I would like to clarify whether the signal in the blue highlight is meant to be SOR or a Reset, and if it is meant to be XeSE1 for Reset instead of a SOR, why is that? What would prompt this from the host? Going by what we see in the waveforms, the activity up until that blue highlight is in-line with what is expected for the auto-resume process:

Kai Lai said:

Success with another hub:

It does look like in this waveform that the pulse on D+ is absent. However, D+ stays high, which would indicate to me that it is still in a suspend state potentially. I would expect to see an SE0 state that is followed by D+ going high, which should indicate EOR and a successful auto-resume:

With this other hub, does the issue with power-saving mode disappear? Does the hub stay enumerated at all times and no longer disconnects?

If switching hubs resolves the issue, this would lead me to believe this could be an issue with the US port of the hub. Our repeater will not send any pulse on D+ while driving D-.

Thanks,

Ryan

Hi Ken,

Ken Lai said:

Because the pulse in blue always exists at EUSB+, no matter in fail or success waveforms.

In this way, the pulse in blue does NOT affect Port/Repeater Configuration & auto-resume result, right?

Ken Lai said:

The pulses in white must be triggered either repeater side or hub side.

Could you help to explain the pulses in white first?

The pulse in blue will have an effect on the state of our repeater. When our repeater sees an XeSE1 on the eUSB2 lanes, the repeater will be reset, requiring the Repeater Configuration to take place again. Additionally, once this configuration takes place, the repeater will no longer be in the state of trying to be completing the auto-resume process.

Instead, our repeater will be looking for a pull-up on the D+ or D- lanes, as it is now waiting for a device connect to take place, so that a USB connection can be set. While in this state, our repeater will NOT be driving any signaling on the USB2 side of the repeater on it's own, and will instead drive whatever passive PU it see's on the D+/D- lanes. The repeater will not drive any pulse on it's own, such as the white pulses captured in the fail waveforms.

Kai Lai said:

Fail:

In the case of the fail waveform, you can see that taking place where after Repeater Configuration takes place, you can see the repeater repeats the PU it sees on the D- lane, as the hub is likely still in that wake/resume state. The repeater is taking the D- PU it sees and driving it on the eDM pin on the eUSB2 side of the repeater. While the repeater is in this state where it is monitoring D+/D- for a device connect, it will not be driving any signaling on it's own, such as that white pulse on D+. Additionally, this pulse on D+ will not appear on the eDP lane, as this will be received by our repeater as a SE1 on the USB2 side, which we consider an error and disregard, as an SE1 should not be possible on the USB2 side of the repeater. As such, I don't believe it can be our repeater driving these white pulse on D+, as our repeater should not be in a state where it is capable of driving signaling on the USB2 side of the repeater.

This is why I believe these pulses are coming from the GL852GT hub, and not our repeater.

Ken Lai said:

might NOT check the waveforms in detail.

Looking at the information that was provided to me, I don't believe I ever received the "success" waveforms. Could you possible send those here, or over the email thread?

I would like to confirm what you mean by "Success" in those waveforms. When you say success, do you mean that those hubs are able to enumerate as expected when using the power-saving mode in the BIOS, and auto-resume performs as expected? Do all the devices connected to the hub enumerate at their expected speed, I.E LS, FS or HS? I see the XeSE1 in all the waveforms, so it looks like the repeater is still being configured each time and SOResume is never being sent.

Do the success waveforms capture the downstream device(s) being successfully connected?

I would also like to check, is there any I2C functionality available? The schematic indicates no, but I wanted to just double check.

Thanks,

Ryan

Hi Ryan,

Attached success log with others HUB for your reference : 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/EUSB1-to-USBA.kvdat

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/EUSB5_5F00_SMSC-HUB.kvdat

Below are feedback from Ken.

If you zoom in the pulse in blue, you would find the following picture, no matter in fail or success case.

There's a very small pulse in pink right after the pulse in blue.

According to eUSB2 spec, the pulse in pink is the handshake of Port/Repeater Configuration.

After that, the pulse in brown shows that Port/Repeater Configuration is complete, right?

USB signals are corresponding to EUSB signals from now on.

I think there might be some way to dump registers of your repeater to confirm if Port/Repeater Configuration is complete or not.

Could you help to check and confirm this?

Fail:

Success with another hub:

------

Now the real question is below, the pulse in white in fail case.

As we know, it's an SE1 which shouldn't pop out here.

As Port/Repeater Configuration is complete, this SE1 is between Repeater side & Hub side.

As EUSB+ never triggers them at the same time, this SE1 must be triggered from either Repeater side or Hub side.

If you think it's triggered from Hub side, please kindly involve GL852GT Hub vendor to debug on this.

QC is unable to comment on Hub-related questions.

Fail:

Hi Kai, Ken,

Kai Lai said:

There's a very small pulse in pink right after the pulse in blue.

According to eUSB2 spec, the pulse in pink is the handshake of Port/Repeater Configuration.

Correct, this pulse is the Port/Repeater configuration taking place. eDP is driven by the SOC, which configures the repeater as a host. The repeater then drives eDM high as an acknowledge. At this point, the repeater should configured as a host repeater

Kai Lai said:

After that, the pulse in brown shows that Port/Repeater Configuration is complete, right?

The pulse in brown shows the repeater has been configured, and it is driving the passive PU signal it sees on the eDM lane.

Kai Lai said:

I think there might be some way to dump registers of your repeater to confirm if Port/Repeater Configuration is complete or not.

Could you help to check and confirm this?

For a register dump, the customer will need to PU SDA/SCL to 1.8V with a 2.2KOhm resistor in order to enable I2C mode. After that point, if the I2C lines are connected to an I2C controller, the registers of the repeater should be able to be accessed via I2C. If possible, being able to use I2C can help to confirm the state of the repeater, hence me asking if the customer (Advantech) can perform this action on their side.

Kai,

Has the customer(Advantech) reached out to Genesys Logic for their input on this issue? Have they been involved in this debugging?

Does Advantech have the ability to enable I2C?

Thanks,

Ryan

Hi Ryan,

Ryan Kitto said:

Has the customer(Advantech) reached out to Genesys Logic for their input on this issue? Have they been involved in this debugging?

 I will let customer to check this with HUB vendor as well later today.

Ryan Kitto said:

Does Advantech have the ability to enable I2C?

I think they don't, but I can bring my Aardvark I2C host to customer side and load dump the register for you.

• Can you please shared a script of Aardvark so that I can load dump the register you want to check ? Or which register you would like to check I can try to do it.
  And BTW, I assume the register status after below red bar should keep the same right?  Then I only need to load dump all the data after that ?
  Or is there a timing request for the log?
• And if there is some pre-program needed been config into repeater when change pin strap mode to I2C mode, please also include into the script of Aardvark, thanks. 

Thanks.

Best,

Kai

Below is GL852GT agent AE feedback,

The GL852GT does not generate SE1 after the resume process.

This SE1 issue is likely a transition phenomenon on the board, and the root cause of the problem is that the host failed to continue the resume from the hub, which is unrelated to SE1.

Furthermore, the SMSC hub (the waveform at bottom one) was not flagged as disconnected because it did not meet the requirements mentioned in the specifications.

11.4.4 Generate Resume (GResume)

A resume condition exists if the C_PORT_SUSPEND bit is set in any port, or if the hub is enabled as a wakeup source

and any bit is set in a Port Change field or the Hub Change field.

Hi Kai,

Kai Lai said:

Can you please shared a script of Aardvark so that I can load dump the register you want to check ? Or which register you would like to check I can try to do it.

We shouldn't need a full register dump. I'm looking to confirm the configuration of the repeater, and there are a few ways to test based on what the customer is seeing:

• For Port Configuration, register 0x20 can be used to read the configuration for port 0. If possible, I would like to read this register before and after the Resume process takes place, and ensure the repeater is configuring as expected, since the host is resetting the repeater mid-resume. There should be no writes needed to read from this register.
• Another register I would like to check is register 0x00. This register can be used to configure EQ0 as a GPIO pin when using I2C and act as a status output. As such, it is best to remove the PD resistor from EQ0, and ensure there is either somewhere to probe pin EQ0. It may be easier to solder a wire so that the signal can be monitored on a scope.
• For register 0x00, you will need to write to it to configure the register to output the correct status. Writing the value 0xA5 will configure EQ0 as an output pin, and allow the register to output the status of port 0. Using this, we can physically monitor when exactly port 0 is configured as a host, and when it is not on a scope. For the procedure, I would recommend using a probe to connect and monitor the EQ0 pin, after the rework above is performed. Then, while the probe is connected to EQ0, write 0xA5 to register 0x00 and monitor the signal while the resume process takes place again.

I will say, the intention of both procedures above is just to ensure the repeater is entering host mode after the auto-resume process begins. The method of reading register 0x20 should be more than enough to confirm we are a host repeater both before and after the auto-resume process begins, but if we wanted to physically track it on a scope while the auto-resume takes place, then the physical rework with the register 0x00 write can be done. I would expect that when Repeater Configuration takes place, our repeater will first enter the Default host after reset, then re-enter host mode.

The method above will not fix anything in the process taking place between the host and the hub, as it appears our repeater is acting as expected given the signaling it is receiving from the host and hub. This is purely just to ensure the repeater is being configured as expected.

Kai Lai said:

And BTW, I assume the register status after below red bar should keep the same right?  Then I only need to load dump all the data after that ?
Or is there a timing request for the log?

The only timing requirement there should be is reading the registers while the USB connection is in suspend, and after the auto-resume process begins.

Kai Lai said:

And if there is some pre-program needed been config into repeater when change pin strap mode to I2C mode, please also include into the script of Aardvark, thanks. 

There should be no pre-programing needed. The only requirement is that SDA/SCL are PU to 1.8V with a 1Kohm to 4.7KOhm resistor, and EQ0 and EQ1 should be PD to GND or floating.

If the customer wants, a system can also be sent to us, and we can perform this on our side here in Dallas. We can verify the customers results on our side, and ensure whether our repeater is not the cause of this issue. We may also try using I2C on our side to see if we can determine any workarounds, though again the repeater should not be the cause of this issue.

Looking at the AE from GLs response, this does align with our understanding of how the host is currently acting as well. Despite the repeater driving eDM high from the signal received by the hub, the host is not responding with a SOResume pulse and is instead communicating XeSE0 to the repeater, resulting in the repeater being reset and the hub not seeing the resume process continue as expected.

Has the customer confirmed whether in the successful cases that the connected device enumerate at their expected data rate or not? Would like to confirm this.

Thanks,

Ryan

Hi Ryan,

Please see I2C and EQ0 UART log and let me know how do you think about it.

In log1 you can see the I2C log which I write A5 to reg 00, log 2/3 are repeat test so no I2C log ; in log 2 / 3 I try to enable the analog channel of USB+ to check that white pulse voltage. 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/20260910-USB_5F00_eUSB_5F00_EQ0_5F00_I2C-log.sal

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/20260910-USB_5F00_eUSB_5F00_EQ0_5F00_I2C-log2.sal

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/20260910-USB_5F00_eUSB_5F00_EQ0_5F00_I2C-log3.sal

And I try to read 0x20 several times during the test, but it always report 0x08, I'm not sure whether it is because it is hard to catch the timing when the status is changing when I try to read it. So, it is better to based on EQ0 pin output for status read, right?  

Ryan Kitto said:

Has the customer confirmed whether in the successful cases that the connected device enumerate at their expected data rate or not? Would like to confirm this.

I will let customer update this later to us.

Thanks,

Best,

Kai

Hi Kai,

Thanks for capturing this. Looking at the waveforms you sent over, it looks like our repeater is performing as expected. It is configured as a host repeater, the SOC sends XeSE1 on eDP/eDM which resets our repeater and takes us out of Host Repeater configuration, before being configured again by the SOC as a host. So going by the logs, our repeater is still performing as expected. I don't see any issue here.

We can also test with register 0x00 set to 0xA4 and 0xA7 to look at the results there as well. 0xA4 would configure EQ0 to output when the repeater is in a default state, which is expected after reset. However at this point, these arent required since it looks like the repeater is performing as expected.

Any update on the customer sending a system to us for testing on our side in Dallas?

Thanks,

Ryan