> I do not always get the USB Suspend event callback
from their code when USB is disconnected from my device.
While USB is unplugged, the USB engine (SIE) on the LPC2364 is unstable. It may
cause spurious interrupts of bus state change by noise on D+/D- line.
Using VBUS pin (P1.30) of LPC2364, detect VBUS pin voltage at the USB connector.
To enable VBUS detect function, PINSEL3.29-28 is set to 10.
While the SIE is enabled, DEV_STAT interrupt is generated by disconnection and
reconnection. While VBUS pin is low, any other spurious USB interrupts are
suppressed.
Instead, you can make the SIE power-down while disconnection, to save power
consumption. In this case, P1.30 is set back to a digital input at
disconnection. GPIO interrupt notifies re-connection. After re-connection, SIE
is initialized again.
This VBUS detect function doesn't work on the first LPC2364 silicon
http://ics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2364.pdf
Tsuneo
--- In l..., "Colby Boles" wrote:
>
> Just an update - checking the frame numbers seems to work very well for
> solving this problem!
>
>
>
> From: l... [mailto:l...] On Behalf
> Of Colby Boles
> Sent: Friday, March 05, 2010 12:27 PM
> To: l...
> Subject: [lpc2000] strategies for detecting USB disconnect on LPC2364
>
>
>
>
>
> I'm using the Keil USB stack with the LPC2364 and everything is
working
> fine, except that I do not always get the USB Suspend event callback
> from their code when USB is disconnected from my device. The usbhw.c
> code that sends this event is pretty straight forward, basically
> forwarding to this event whenever a USB interrupt occurs and the
> DEV_SUS_CH and DEV_SUS bits are set in the device status register when
> it is read. I can only assume this means that sometimes these bits just
> don't get set (or the IRQ never happens) when you remove the USB
> connection.
>
>
>
> Since my hardware is already designed without the ability to sense Vusb
> directly, what other strategies can I use to reliably detect that no USB
> host is connected?
>
>
>
> I was thinking I could periodically poll the frame number to see if it
> continually advancing, and if it has not over some period of time I
> could assume a disconnection. I wonder if there are certain cases during
> enumeration or transition to other power modes where I may falsely
> detect disconnection using a method like this?
>
>
>
> Has anyone else encountered or solved this problem?
>
>
>
> Colby
>
