When the XEM is being disconnected


Hi Jake,

I was wondering if you could answer to this question. I’m writing a class that incorporate all FPGA controls and exceptions for my application (I would like to avoid using WM_DEVICECHANGE at this level).

When I unplug the XEM my software reports 0 as result of a GetDeviceCount(). So far so good. When I plug the XEM again (without deallocating my okUsbXEM3001v2 instance), GetDeviceCount() returns 1. At this point the communication doesn’t work anymore. If I deallocate/allocate the instance of okUsbXEM3001v2 I use to communicate, I obtain the same result. If i quit the application and start over, no result. No connection. Finally if I unplug/plug the XEM and start again the application, everything goes well.

What can I do to avoid this behavior? Any advice?




The suggested way to handle this in Windows is to rescan for devices whenever a device change has been noticed (the WM_DEVICECHANGE event that you indicated).

Therefore, whenever that message comes in, you should deallocate all existing instances of okCUsbXEM3001v2 and reallocate them. This is how the FrontPanel application works, in fact.

As far as I know, this is the only way to reliably handle a disconnect. Once a DEVICECHANGE message is sent around (and is valid for your device), you should discontinue using that instance. I’m not really sure how the OS handles communications after that – afterall, all the device structures and so on are invalid.


Hi Jake,

thank you for answering the question! As the matter of fact, if I perform this sequence:

  1. unplug 2. deallocate 3. plug 4. allocate

Everything works in the way you mentioned. However, I’m in the situation where I must perform this sequence:

  1. unplug 2. plug 3. deallocate 4. allocate

I understand it’s a weird situation, but I was wondering if it is contemplated in your library/drivers, and if not, there is anything you can do about it. In case this is only a Windows matter… well I give up :slight_smile:



Hi again-

Unfortunately, I cannot speak for the way the OS works in this case. I’m not sure which structures survive after a DEVICECHANGE event. Since our driver works at a higher level than the base USB support within the OS, there are several layers where something strange could be going on.

Why is it that you cannot process the DEVICECHANGE event?


Hi Jake,

unfortunately, the interface we are building using the XEM is “windows event-independent”. We cannot rely on the WM_DEVICECHANGE to properly manage the link between the FPGA and the PC.


I see. I wonder if there may be a Windows API that allows you to poll for a DEVICE CHANGE ?


A solution could be to force a new enumeration only of the XEM, but I didn’t try it yet. The enumeration+deallocation of the XEM would update all information about the USB drivers.