i.MX25 usb wake connect/disconnect

[stephenbialkows]

Hello,

I am targeting an i.MX25 on a custom board.  We wish to have the system wake from stop upon USB wake.  The problem is this [dis]connect wake event doesn't happen, despite my best efforts to connect the dots in the reference manual.  Unfortunately, all similar questions are in the context of a Linux environment, which ignores the low level details that I need to understand.  Any insight that could decrease the velocity of my head spinning will be much appreciated! 

I am operating off the assumption that it's sufficient to reset the USB core, put it in device mode, enable the wake events, wait for the OTG port to suspend, then activate the low-power USB interrupts in the CCM and ASIC registers.  I believe that putting the port in suspend enables the power control module, which monitors the bus for activity, and generates the wake interrupt according to the wake enables in the USB CTRL register.  

There are preconditions in changing the registers of interest.  I believe the registers are being set correctly.  Here's a summary how the registers are written:

read:  0x       0 from MX25_USBCMD stop @ 0x 19fa140
wrote: 0x       2 to MX25_USBCMD reset (2 is cleared when complete, ignore upper word) @ 0x 19FA140
 read:  0x   80000 from MX25_USBCMD @ 0x 19fa140

Some writes are omitted here.  Here is the register summary after device detect routine: 

USBMODE:00000002 USBSTS:01000080 OTGSC:00000D20 USBCMD:00080001 PORTSCX:10000805 USB_CTRL:000D0870: B device detected

In summary, the device is running/attached and suspended. 

Interrupts are enabled next:

wrote: 0x   50870 to USB CTRL clear wake interrupts @ 0x 19FA600
wrote: 0x   50870 to USB CTRL clear wake flags @ 0x 19FA600
wrote: 0x181dc870 to USB CTRL enable wake interrupts @ 0x 19FA600
wrote: 0x       0 to MX25_USBINTR disable normal interrupts @ 0x 19FA148
wrote: 0xffffffff to MX25_USBSTS clear interrupt flags @ 0x 19FA144
wrote: 0x10300885 to MX25_USB_UOG_PORTSC enable port wake interrupts @ 0x 19FA184
FAILED: wrote 0x10300885 to MX25_USB_UOG_PORTSC (wake on [dis]connect is read-only in device mode), read back: 0x10000885
wrote: 0x10300885 to MX25_USB_UOG_PORTSC suspend @ 0x 19FA184
FAILED: wrote 0x10300885 to MX25_USB_UOG_PORTSC suspend, read back: 0x10000885
UOG port suspend confirmed...
read: 0x10000885 from MX25_USB_UOG_PORTSC @ 0x 19fa184
read: 0x       0 from MX25_USB_UHG_PORTSC (host port shouldn't matter here) @ 0x 19fa384

Here's what the ASIC registers look like right before issuing the wfi instruction.  As you can see, both USB interrupts are enabled, there are no pending interrupts, all IRQs have the same (highest) priority, IRQs are enabled, FIQs are disabled.  Note that hardware acceleration for the USB interrupts is enabled via the ASIC INTENNUM register. 

read: 0x  200000 from ASIC INTCNTL @ 0x 1973000
read: 0x       0 from ASIC NIMASK (disable val and lower irqs) @ 0x 1973004
read: 0x 218202c from ASIC INTENABLEH (1-enabled) @ 0x 1973010
read: 0x12810438 from ASIC INTENABLEL @ 0x 1973014
read: 0xffffffff from ASIC NIPRIO7 (priorities) @ 0x 1973020
read: 0xffffffff from ASIC NIPRIO6 @ 0x 1973024
read: 0xffffffff from ASIC NIPRIO5 @ 0x 1973028
read: 0xffffffff from ASIC NIPRIO4 @ 0x 197302c
read: 0xffffffff from ASIC NIPRIO3 @ 0x 1973030
read: 0xffffffff from ASIC NIPRIO2 @ 0x 1973034
read: 0xffffffff from ASIC NIPRIO1 @ 0x 1973038
read: 0xffffffff from ASIC NIPRIO0 @ 0x 197303c
read: 0x       0 from ASIC NIPENDH (pending?) @ 0x 1973058
read: 0x       0 from ASIC NIPENDL @ 0x 197305c
read: 0x       0 from ASIC FIPENDK @ 0x 1973060
read: 0x       0 from ASIC FIPENDL @ 0x 1973064

I believe the 32KHz clock is running (assuming its the same clock that the DryIce module uses) because the RTC timer will wake the target.  I have only seen one disable flag in the DryIce control register (OSCB).  I'm sure it's not set. 

A few concerns:

 1) The wake on [dis]connect flags in the UOG PORTSC1 register are read only.  I have to assume this functionality is always on considering the RM says device mode supports wake on [dis]connect. 

 2) I noted a question in the iMX6 community where a user reported the over-current condition was getting in the way of a remote wake event.  We are not trying to wake the host.  But I am curious if that could get in the way of [dis]connect or traffic wake events.  The over-current flag appears to be stuck set on this target during normal USB operation.  

 3) The wake interrupt is asynchronous.  I'm a little concerned about the BYPASS_EN bit being read-only and cleared in the ASIC INTCNTL register.  The description reads: when reset (reset value=0), disables propagation of asynchronous interrupts. 

Thanks,

Stephen

[stephenbialkows]

Thanks Igor,

I'm not familiar enough with Linux to know where to look.  Google is unable to find the pertinent suggested reading documents in the attached mx51_linux.pdf:

i.MX51PDK Linux Quick Start Guide

BSP API Document

i.MX51PDK Linux User’s Guide

Do I have to request these documents from Freescale?  Do you have copies you can attach?

Regards,

Stephen

[igorpadykov]

Hi Stephen

please look at Linux documentation

https://www.nxp.com/webapp/Download?colCode=IMX51_ER1011_LINUXDOCS_BUNDLE 

Linux 2.6.35 Source Code Files and documentation

Linux 2.6.35 Source Code Files and documentation 11.03 for i.MX53 SABRE Tablet 

Best regards
igor

[igorpadykov]

Hi Stephen

I am not aware of i.MX25 usb wake up implementation in nxp bsps, seems

one can look at i.MX51 (has similar usb module) and attached Linux Manual

sect.29.11 USB Wakeup usage, check sources in

Board Support Packages (8)
Linux 2.6.35 Source Code Files
https://www.nxp.com/products/power-management/pmics/power-management-for-i.mx-application-processors...

Please pay attention to plls errata ENGcm12381,ERR007917

https://www.nxp.com/docs/en/errata/IMX25CE.pdf 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------