IMX27L OTG ULPI Connection Issue.

[WILLIAMDIONGSHI]

I'm designing IMX27L as a device with WINCE OS.In my existing design, I am using ISP1507 for USB Transceiver on IMX27L OTG port without any connection issue. Due to EOL of ISP1507, I had changed my USB Transceiver to USB3311. Now my IMX27L having lost connection to the host after doing few rebooting cycles. Do we need to update the software portion since I changed the USB Transceiver? What criteria do I need to look at for the connection wise?

[VladanJovanovic]

Dileepa Prabhakar said:

Vladan Jovanovic said:

Dileepa Prabhakar said:

To be clear, the issue we are seeing is that occasionally, typically after a power cycle, the transceiver does not appear to detect that a USB cable is connected to it. No amount of reconnecting will fix the issue and the only workaround is to perform a power cycle.

Dileepa, one reason for this might be that, by default, USB core is set up for serial transceiver interface. We've seen sometimes that this can cause, while reconfiguring to ULPI setup, issue with some transceivers on i.MX27. Problem appeared randomly and immediately after powerup, as you describe it.

Is this then a known issue with i.MX27 OTG controller then (do you know)? I didn't notice any information in the errata.

It's not an errata, it's just a consequence of default USB controller setup which causes some contention on the lines during setup. Ideally, you would use CS to disable PHY while reconfiguring the controller.

I'm not sure why reconfiguring GPIO MUX only after USB controller is switched to ULPI mode breaks the detection. In any case USB controller doesn't communicate with PHY before GPIO MUX and ULPI mode are configured...

[DileepaPrabhaka]

Vladan Jovanovic said:

Dileepa Prabhakar said:

To be clear, the issue we are seeing is that occasionally, typically after a power cycle, the transceiver does not appear to detect that a USB cable is connected to it. No amount of reconnecting will fix the issue and the only workaround is to perform a power cycle.

Dileepa, one reason for this might be that, by default, USB core is set up for serial transceiver interface. We've seen sometimes that this can cause, while reconfiguring to ULPI setup, issue with some transceivers on i.MX27. Problem appeared randomly and immediately after powerup, as you describe it.

Is this then a known issue with i.MX27 OTG controller then (do you know)? I didn't notice any information in the errata.

One solution to this problem could be to switch i.MX27 USB controller to ULPI mode before GPIO MUX is reconfigured for USB operation.

I tried this, but the USB-connected-on-boot detection is broken. I.e., if a device is already connected during boot, it is not detected as being connected. I have to unplug and replug the device for the driver to detect a connection. I tried several things (like re-selecting transceiver type again after GPIO initialization), but nothing helped. It looks like changing transceiver type also causes the i.MX27 to reconfigure the transceiver, which cannot happen if the port pins aren't initialized yet.

Other (better) option is to de-assert CS to the PHY after PHY_CLK starts to run. Rest of setup is done as usual and only at the end of USB initialization is CS asserted again. Unfortunately, not all designs have the CS connected to some GPIO on i.MX27.

Unfortunately, that's not an option in our case because of the reason you stated above.


Thanks a lot for your suggestions!

--Dileepa

[VladanJovanovic]

Dileepa Prabhakar said:

To be clear, the issue we are seeing is that occasionally, typically after a power cycle, the transceiver does not appear to detect that a USB cable is connected to it. No amount of reconnecting will fix the issue and the only workaround is to perform a power cycle.

Dileepa, one reason for this might be that, by default, USB core is set up for serial transceiver interface. We've seen sometimes that this can cause, while reconfiguring to ULPI setup, issue with some transceivers on i.MX27. Problem appeared randomly and immediately after powerup, as you describe it.

One solution to this problem could be to switch i.MX27 USB controller to ULPI mode before GPIO MUX is reconfigured for USB operation.

Other (better) option is to de-assert CS to the PHY after PHY_CLK starts to run. Rest of setup is done as usual and only at the end of USB initialization is CS asserted again. Unfortunately, not all designs have the CS connected to some GPIO on i.MX27.

Hope this helps.

Vladan

[fabio_estevam]

I have also tested OTG device-only mode (using g_ether) and did not see the error you mentioned.

Can you give the mainline kernel a try?

Regards,

Fabio Estevam

[DileepaPrabhaka]

Fabio,

It doesn't look like the ULPI driver (ulpi.c) is used in device-only mode (which is what linux-2.6.32.25 supports -- no OTG support there). We use the Timesys i.MX27 port of linux-2.6.23.35.

The OTG port is configured as a device and is used by the gadget driver (g_serial in our case). Only the fsl_udc_core and fsl_usb2_udc drivers appear to be in use.

Was your change to ulpi.c made to fix this particular issue?

To be clear, the issue we are seeing is that occasionally, typically after a power cycle, the transceiver does not appear to detect that a USB cable is connected to it. No amount of reconnecting will fix the issue and the only workaround is to perform a power cycle.

Thanks,

Dileepa

[fabio_estevam]

Dileepa,

Please try the latest kernel from kernel.org. USB331x does work on the mainline kernel.

I tested it and also submit a patch for it: http://www.spinics.net/lists/linux-usb/msg40626.html

Regards,

Fabio Estevam

[DileepaPrabhaka]

We've seen a similar issue on the i.MX27L OTG port configured to operate only as a device running linux-2.6.32.25. We are using a SMSC USB3317 transceiver.

Would appreciate any updates if you've found a solution or a workaround.

Thanks,

Dileepa