AnsweredAssumed Answered

i.MX25 usb wake connect/disconnect

Question asked by Stephen Bialkowski on Nov 22, 2017
Latest reply on Nov 28, 2017 by igorpadykov


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.