Under certain circumstances "Flushing/De-priming an Endpoint" never completes

[jamesledwith]

I've run into a scenario where "Flushing/De-priming and Endpoint" as described in the iMX 25 reference manual (Section 47.5.7.5.5) never completes because the ENDPTFLUSH register is never set to zero.

The scenario is very specific - I have an externally powered device (with an iMX-25) connected via USB to a host (Windows laptop). Then a user powers down the host. The USB cable and external power are still connected. The device detects the loss of connection and in software closes the USB interface/driver.

While closing the USB driver, the driver attempts to flush all endpoints. In this specific sequence of events the process described in 47.5.7.5.5 never completes because the ENDPTFLUSH register never clears to all zeroes, it stays stuck at 0x00FF00FF. The reference manual does not describe what to do in the event that the ENDPTFLUSH register never clears, it just says "Wait until all bits are 0."

If a user unplugs the USB cable, causes a reset, or re-enumeration the endpoint flush works as described. We've only seen this error under these very specific conditions.

I have a few questions:

1 - Is it proper practice to flush all endpoints when closing a USB connection? Depending on the device configuration we could have 2 or 3 endpoints primed to read at any given time.

2 - What should be done in software in the event that the ENDPTFLUSH register never goes to zero?

[jamesledwith]

Thank you Richard, enabling the PHY clock will address the issue.

You were correct about the order of events. The host placed the device into USB suspend then power was shut off. Our externally powered device detected the USB connection drop and tried to close the driver which performed a flush all buffers while the chip was in low power/suspend mode. Enabling the PHY clock prior to flushing the buffers allows the flush to complete.

[richard_stulens · Accepted solution]

I suspect that the PHY is in low-power mode by the time the endpoint flush is attempted.

For the flush operation to work, the PHY clock must be running. You can program the endpoint registers with the PHY clock stopped but the flush operation will only execute when also the PHY clock is active (i.e. PHY is not in low-power mode).

I'm assuming that on a cable disconnect the PHY will not be powered down before the flush operation is executed, but on a PC-power--down, everything is much slower and hence the bus may have been idle for while before VBUS power is removed. In this scenario, USB driver software may have placed the PHY in low-power mode (and thus stop the PHY clock)  because of the idle condition (suspend) and later detects the VBUS drop at which time it tries to de-queue and flush endpoints.

To fix the problem it is likely sufficient to clear the PHCD bit in the PORTSC register to re-activate the PHY and then flush the endpoints, but it depends on the software.

Best regards,

Richard

[jimmychan]

This may useful for you.

http://www.freescale.com/files/dsp/doc/app_note/AN3683.pdf

[jamesledwith]

We're aware of the workaround for errata BID2108. That has been implemented and does not appear to impact the behavior we're seeing.