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.
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.
thank you for answering the question! As the matter of fact, if I perform this sequence:
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:
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
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?
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.
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.
