USB1 host-mode port reset issues with high-speed devices

[iankalinowski]

I've noticed some questionable behavior in the PORTSC1 register for USB1 in host-mode when connecting/disconnecting high-speed devices.  This issue does not occur with low-speed or full-speed devices.  The first time I connect a high-speed device to USB1 (J12 on the Vybrid MPU board), the PORTSC1.CSC (bit 1) and PORTSC1.CCS (bit 0) bits get set, indicating that a new device was connected.  I then set PORTSC1.PR (bit 8) to reset the port, then wait until the EHCI controller clears PORTSC1.PR, at which point the EHCI controller sets PORTSC1.PE (bit 2) to indicate that it has enabled the port.  For example:

    (I connect a high-speed device)

    Read:  0x10001803    (controller sets CSC and CCS to indicate a new connection)
   
    Write: 0x10001803    (clear the CSC flag)

    (wait 100 milliseconds)

    Read:  0x10001801    (CCS is still set as the device is still connected)

    Write: 0x10001901    (tell the controller to reset the port)

    (spin-wait until PORTSC1.PR is cleared)

    Read:  0x18001205    (controller has cleared PR and set PE)

So far, so good.

When I disconnect the high-speed USB device, the EHCI controller sets PORTSC1.PEC (bit 3) and PORTSC1.CSC (bit 1) to indicate that the device was disconnected and the port is disabled.  For example:

    (I disconnect the high-speed device)

    Read:  0x1c00100a    (controller sets PEC and CSC)

    Write: 0x1c00100a    (clear the PEC and CSC flags)

    Read:  0x1c001000    (nothing is connected to the port)

So far, so good.

The questionable behavior occurs after I reconnect the original high-speed device back to USB1 (J12).  In this case, after I set PORTSC1.PR and wait for the EHCI controller to finish resetting the port, PORTSC1.PE does not get set to indicate that the EHCI controller enabled the port.  For example:

    (I reconnect the high-speed device)

    Read:  0x10001803    (controller sets CSC and CCS to indicate a new connection)

    Write: 0x10001803    (clear the CSC flag)

    (wait 100 milliseconds)

    Read:  0x10001801    (CCS is still set as the device is still connected)

    Write: 0x10001901    (tell the controller to reset the port)

    (spin-wait until PORTSC1.PR is cleared)

    Read:  0x1c00100a

    (strangely, the controller set PEC and CSC to indicate that the connection status changed; notably, PE is clear to indicate that the port is disabled and CCS is clear to indicate that the device is not connected)

    Subsequent reads from PORTSC1 returns 0x1000180b (PE = 0, CSC = 1, CCS = 1), indicating that the a device is connected but the port is disabled.

From this point forward, attempting to reset the port (by setting PORTSC1.PR) results in the same behavior when a high-speed device is connected.  If a low-speed or full-speed device is connected, the port properly resets; however, when subsequently connecting a high-speed device, the controller fails to enable the port after the port is reset.

It appears that resetting the entire EHCI controller will allow the port to properly reset again but this approach seems a bit overkill.  Is there a better way to work around this issue aside from resetting the entire controller?  If possible, I'd prefer not to use USB PHY interrupts (though I haven't investigated this approach).

In case it helps, I've set ENUTMILEVEL3, ENUTMILEVEL2, ENHOSTDISCONDETECT in USBPHY1_CTRL (by the way, ENHOSTDISCONDETECT should probably be mentioned in Table 8-19 in the Vybrid Reference Manual).

Thanks,

Ian

[iankalinowski]

According to section 44.6.4.1.3 "Discovery-EHCI Deviation" in the Vybrid Reference Manual (Rev. 5), the port enable will always be set after the port reset operation.  Therefore, this looks like a hardware bug to me.  The VYBRID_1N02G errata list (rev 1.1) does not appear to list anything related to this problem.

Can anyone confirm whether this is a known (but as of yet undocumented) hardware erratum?  Should we expect this to be fixed in a future board revision or will a software workaround be required?

[richard_stulens]

Hello Ian,

I have not heard of such issue before, therefore I'd like to get some more info so I can try to find what may be causing it.

Can you capture the USB signals Dm and Dp  with a sope (preferably 1 GHz or better) during the reset?

I.e. set timebase to 20 ms/div, trigger on falling edge of Dp with trigger level set to 1.5V. Trigger position at the left of the screen.

I like to see what happens on the bus when this problem occurs.

Some other questions

• Is this on the tower board that you see this issue? If so, what revison board is it that you have? (stickers SCH-xxx and 700-xxxx).
• How do you power the board? Elevator supply or Vybrid board debug USB connector?
• Did you try with multiple different devices?

[vitech]

Got the same problem, seems like something must be reinitialized after the reconnection. Full-speed devices works fine, but high-speed port refuses to enable after port reset

[richard_stulens]

After reading the whole thread again, it occurred to me that this may be related to an issue we had with false disconnect detection.

The issue was caused by the host (Vybrid) sending SOF too soon after HS negotiation. When this occurs before the device has enabled its HS termination, the HS-disconnect detector may trigger and the device was reported as disconnected. This issue would occur after a resume from suspend but I wonder if you may be seeing this issue.

On the current silicon (2N02G), this issue has been fixed, but the fix must be enabled by software. This will be documented in the next RM release.

Bit 16 of the USBPHYxIPn register is an identifier for the fix. If this bit is set, then the hardware fix is preset.

To enable the hardware fix, please set bits 17 and 18 during initialization of the controller & PHY.

If Bit 16 is not set, disable the disconnect detector when the port is not in high-speed mode (prior to bus reset, during suspend etc) and re-enable once the port is operating in high-speed mode.

If none of this helps, please capture the failing reset event with a scope (Dm/Dp) and post it here.

Thanks & regards,

Richard

[vitech]

Hello richard_stulensrichard_stulens

Thanks for fast reply, one more thing:

As you say, I set bit 1 ENHOSTDISCONDETECT in USBPHYx_CTRL register when plug HS device to host & clear it when device is disconnected.

During disconnect interrupt bit 3 HOSTDISCONDETECT_IRQ in USBPHYx_CTRL is also set, so question is how to clear this bit? Tried by writing to USBPHYx_CTRL_CLR register but nothing happens.

[richard_stulens]

You should not have to enable the interrupt in the PHY. The Host controller will generate a port change interrupt when a HS-disconnect occurs.

To clear the bit, write a ‘1' to the USBPHY0_CTRL_CLR address. All the PHY registers have 4 addresses (R/W, SET, CLEAR, TOGGLE). See USB memory map for details.

HOSTDISCONDETECT_IRQ

Indicates that the device has disconnected in high-speed mode. Reset this bit by writing a 1 to

theSCT clear address space and not by a general write.

Address                 Register

4005_0830           USB PHY General Control Register (USBPHY0_CTRL)                              32 R/W C020_0040h 45.2.4/2388

4005_0834           USB PHY General Control Register (USBPHY0_CTRL_SET)                    32 R/W C020_0040h 45.2.4/2388

4005_0838           USB PHY General Control Register (USBPHY0_CTRL_CLR)               32 R/W C020_0040h 45.2.4/2388

4005_083C          USB PHY General Control Register (USBPHY0_CTRL_TOG)                   32 R/W C020_0040h 45.2.4/2388

Regards,

Richard

[vitech]

As I understand, HS-disconnect detector enable via setting bit 1 ENHOSTDISCONDETECT bit in USBPHYx_CTRL reg, without it no port connection state change interrupt generated during HS-device disconnect from port. So when I disconnect HS-device with this bit set, interrupt is generated and bit 3 HOSTDISCONDETECT_IRQ in USBPHYx_CTRL set to 1, but I can't clear it by writing  to USBPHY_CTRL_CLR cause it's continue being set after writing. After reconnection HS-device I still have no port enable after port reset, must I clear HOSTDISCONDETECT_IRQ for proper work? It looks to me port cannot be enabled after first disconnect detection cause I miss to clear something

[richard_stulens]

ENHOSTDISCONDETECT must only be enabled when the bus is in high-speed mode, so only enable after bus reset has completed (and PORTSC.PSPD indicates High Speed) and disable when disconnect is detected or when bus is suspended.

PLEASE also check if bit 16 in the PHYx_IPn register is set. If it is, just set bits 17 and 18 in the same PHYx_IPn register. This will take care of the false detection and you can leave disconnect detection enabled. If bit 16 is not set, then you have to enable and disable as described above.

Best regards,

Richard

[vitech]

Even with bit 16 set in PHYx_IP reg and after I set bits 17 & 18, I still need to enable and disable disconnect detector. It works well now when I enable detector after each port reset when high-speed device is detected and disable after each port disconnect. But when I tried to leave detector enabled after initialization without toggling on port changes, behavior discribed above occurs.

At least I can work with high-speed devices now, but for future it would be nice to have detector enabled for a lifetime, some more few strings in RM could be helpful :smileyhappy:

[richard_stulens]

Thanks for the feedback. I'll check this with design.

My understanding was that Bits 17 & 18 would fix the requirement for software interactions. We'll add more information to the RM regarding this requirement.

Best regards,

Richard

[richard_stulens]

I checked the details with the design team. They say the enable bit (ENHOSTDISCONDETECT) must be toggled OFF/ON to reset the disconnect detection flag.

That matches with the sequence that you apply, so that is appropriate.

Best regards,

Richard