I don't seem to get any USB Disconnection interrupt. I tried the usb-dev-serial and the usb-dev-msc projects on a DK-LM3S9B96 eval board and also on my own board with a LM3S9U96. The LCD never showed "Host Disconnected" nor breakpoint for USB_EVENT_DISCONNECT ever triggered inside the interrupt handling routines. I searched the web for two days and found only one mentioning in Marc 2011 and that wasn't a real solution either: monitoring USBxVBUS.
What prompted this search was that when running usb-dev-msc on a DK-LM3S9B96, ejecting the drive on Windows 7 64-bit Professional always failed. Closing the USB device from the bottom right corner of the windows task bar worked, but the .close function was never called on the usb-dev-msc side.
Any help would be appreciated.
Sam
Sam,
I have been able to replicate this problem. I will take a look at the code in usblib, talk to my coworkers and let you know what can find out.
Thanks,
Sean
Sean,
Thanks for looking into this. I did find one line which is probably wrong. I think it is in usbdmsc.c. The routine HandleDisconnect has
If (psDevice->psPrivateData->pvMedia == 0)
I think "==" should be “!=”. But that didn’t solve the problem since the interrupt was never generated to begin with. I did check the USBIS and USBIE registers, they were set correctly with DISCON bit set in USBIE.
Sam.
I found that the change you suggested has already been integrated into the latest version of usbdmsc.c. You should see it in the next release.
I'm still trying to determine why the interrupt is not triggering. I'm not seeing the bit get set in the USBIS -- I'm seeing the CONN bit set, not DISCON. The USB expert has been out this week, so I'll hopefully have an answer on Monday.
I tried the usb_dev_msc example on my dk-lm3s9b96 board with RevC silicon and I'm getting a disconnect interrupt. It appears that I wasn't getting a disconnect interrupt on my ek-lm4f232 due to errata 10.1. Do you know what revision of silicon you are using on your boards? What voltage is your VBUS pin going to after you disconnect?
As for disconnecting within Windows, I was told that there currently is not a way for the device to detect the change.
I have a dk-lm3s9b96 board with RevC silicon too (IQC80C3XD). Where did you look for the disconnect interrupt? USBDMSCStorageClose was never called. I added USB_EVENT_DISCONNECTED case to USBDMSCEventCallback in usb_dev_msc.c and the USB_EVENT_DISCONNECTED was never received. I went all the way back to the usblib code and didn't see any DISCONNECTED event.
The VBUS pin reads 5V when connected, as expected. When the USB cable is removed, it drifted back to 3.3V which was the internal pullup of the VBUS microntroller pin, I believe. Same voltages measured on the dk-lm3s9b96 board and on my own board.
Regarding your last statement, are you saying that when I eject the device on the Windows side, the disconnect event from the Windows side would never be detected by the microcontroller? Does the USB module inside the ucc rely on the disappearance of the VBUS voltage to generate a DISCONNECT? If so, then an external pulldown resistor would be required on the VBUS pin, right? I guess one solution, as pointed out by a post last year, is to add the pulldown resistor and use the VBUS pin to generate a generic GPIO interrupt.
The only reason I'm fixated on the DISCONNECT event is that I'm implementing the storage with a SPI serial flash IC. The DISCONNECT event would allow me to flush pending writes to the IC.
Thanks.
I'm looking in the USBIS register for the interrupt. I'm also seeing HandleDisconnect and USBDMSCStorageClose called. When I disconnect the cable, I see vbus on my dk-lm3s9b96 board go from around 5V to 0V. There shouldn't be a pull up on VBUS -- if it is at 3.3V, then there is problem. The interrupt is only generated when the voltage goes below a threshold in OTG mode. If you force Device mode, then you will not get the interrupt due to errata 13.4. Have you modified the usb_dev_msc example? Try a clean copy from the 8555 release and see if you still get the problem.
The disconnect operation in Windows is just used to flush pending buffered writes to the device before unplugging it. The disconnect interrupt is purely based on the VBUS level.
I didn't realize that there is a newer 8555 release. I was running the one that came with the dk-lm3s9b96 kit.
I downloaded the 8555 release and tried to recreate the usb_dev_msc project. Somehow this release did not create all the necessary folder links to the driver folders. So the project didn't build correctly, complaining about a bunch of unresolved objects. I was following the Quickstart-Eval-kit-CCS.pdf file from the CCS dvd that came with the dk-lm3s9b96 kit. Is there a newer file?
Thanks.Sam.
I added the missing file links to the usb_dev_msc and got it working. You were right, DISCONNECTED events were indeed generated with the 8555 release. Sorry to have troubled you.
Are there example projects that put usb_dev_msc and usb_dev_serial into a composite device?
You can download the latest quickstart here: http://www.ti.com/litv/pdf/spmu057e
Sorry, we don't have an example of a composite device with those two.