Multiple devices with same VID/PID problem

[jona]

I am writing a windows app to control multiple devices with the same VID/PID. Quickly detaching one and attaching another often yields only the Detach sound in Windows, but never the re-attach. As well, it seems as if the detach notification never makes it to my app. I tested this in a USB snooper and the same thing occurs. Does the driver use device descriptors to do any differentiation? Is there a solution to this?

The device descriptors for the devices is the same on each one.

Stuck!

Thank you.

[Jan Axelson]

If the devices have identical descriptors, the application can't distinguish between them. Can the application access the device after reattachment? Wait a few seconds between detach and reattach.

[jona]

Thank you Jan.  So, if I put the device's serial number in the descriptor, Should I expect the driver to differentiate? Or does the driver never look at that. The problem is that during quick detach attach scenarios, I hear the detach sound, but never hear the attach sound and notifications are not sent to my app. ( we're creating the firmware and the windows app)

(BTW, thank you for all of your work over the years, your book was indispensable in the early 2000s on my first USB project)

[Jan Axelson]

The host should be able to detect detach and reattach whether or not the device has a serial number. But if you are doing quick detach and reattach, for testing for example, the host might have a hard time dealing with it. That's why I suggested waiting a few seconds before reattach. Do you still see the problem if you do that?

I'm glad to hear you found my book useful!

[jona]

The problem is that the app never receives either detach or attach notifications in this case. Our target is to eliminate that problem if we can. I was assuming it is because all of the units look alike to the driver and the app. Does the driver use the descriptor to differentiate between devices in any way?  If so, then adding the serial number to the descriptor should solve  the problem.  In a previous app I created for this same client I I don't recall coming up against this issue. But I don't recall a lot of things anymore

This application uses two methods to communicate to these units. One is a direct USB connection and the other is through a dock which can contain up to 16 of them. You can have as many docks and units as you have USB connections.

This is the system:
https://www.listentech.com/wp-content/uploads/2017/02/ListenTALK-End-User-Brochure-LTR-Trifold_WEB_1.pdf

Thanks Again.

[Jan Axelson]

Just a quick comment - my HID and Winusb applications at janaxelson.com detect attach/detach, in case you can find a clue there.

Serial numbers affect how Windows looks for a driver but not whether to send notifications as far as I know.

[jona]

Thanks Jan. That's kind of what I thought. I have detection code that I've been using for a long time and it does work flawlessly but this issue is a nuisance.

[Jan Axelson]

If it happens only when users are doing fast detach and reattach, I don't know of a solution other than advising users not to do it! I don't know of any standard that specifies the minimum delay between detach and reattach, but reasonably one wouldn't expect users to be detaching and reattaching quickly so it's not surprising if hosts don't test for it.

[Bret]

... reasonably one wouldn't expect users to be detaching and reattaching quickly ...

I disagree with this statement.  I would agree that developers don't like it when this happens, but it's perfectly reasonable for users to do whatever they want whenever they want and expect the system to react appropriately.  This is especially true when systems tend to be so unreliable that the standard resolution these days is to "reboot and hope it works the next time."  Unplugging and replugging (whether quickly or slowly) is equivalent to rebooting, and has become the standard way to fix things.

The system is the "slave" and the user the "master", not the other way around.

[Jan Axelson]

Agree, but seems to be true that Windows doesn't concern itself with it perhaps in part because the specifications say nothing about it nor do compliance tests as far as I know.