I have a USB device that exposes a USB single interface on 1st plug in, then after a firmware download and soft disconnect, exposes 2 USB interfaces.
The problem with this is that on first driver installation, our vendor driver is installed without the underlying composite device driver (usbccgp.sys). When the device is re-enumerated with the 2 interfaces, Windows loads our device driver without first loading usbccgp.sys. The only way to get usbccgp.sys installed is to first uninstall our driver from DevMgr (without unplugging the device), then re-installing the driver. In this case I am able to load a driver for each interface, which is the desired outcome
Is there any way to configure the .inf file to get around this problem?
I have a USB device that exposes a USB single interface on 1st plug in, then after a firmware download and soft disconnect, exposes 2 USB interfaces.
The problem with this is that on first driver installation, our vendor driver is installed without the underlying composite device driver (usbccgp.sys). When the device is re-enumerated with the 2 interfaces, Windows loads our device driver without first loading usbccgp.sys. The only way to get usbccgp.sys installed is to first uninstall our driver from DevMgr (without unplugging the device), then re-installing the driver. In this case I am able to load a driver for each interface, which is the desired outcome
Is there any way to configure the .inf file to get around this problem?
We actually had a discussion about this very issue last year. There is
no good software solution to this problem. Is this an FX2?
Here are your choices.
Burn your firmware into EEPROM instead of loading it dynamically.
This is the solution I now prefer.
Use a different VID/PID for the non-loaded state. Your “requirement”
that the device use a single PID is probably some misguided marketing
requirement that was produced with no understanding of the technical
issues involved. What, after all, is the downside of using a second
PID? Have you even asked the question?
Modify your unloaded descriptors to include a dummy second
interface. However, if you have this ability, then you can also
implement option 1.
Embed usbccgp.sys’s functionality into your driver, so you become a
bus driver when you detect that the firmware is loaded. That’s ugly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Not possible I’m afraid. The VID/PID must remain the same through > enumerations. > > Nick Clarke > www.redsoftsys.com > > The information about your device (descriptors and what driver to load) is probably cached in somewhere like HKLM\SYSTEM\CurrentControlSet\Enum. I seems to me (warning speculation ahead) that windows just asks the device on reconnect for the device descriptor and if it matches what is cached does not bother requesting the interface descriptors etc before choosing what driver/s to load.
If there were some way pragmatically to purge this cache I would be really interested to know.
Also perhaps if you change the REV/bcdDevice field with the new firmware the device will be fully re-enumerated.
re the second PID idea, I did ask the question, it did occur to me that this would be a neat way out of the situation. However, we are developing this product for OEM use and one of the strategies is to allow OEMs to program their own VID/PID pairs, so we are already hamstrung on that one.
We’ve decided to change the descriptors and handle all the device functionality in one driver, using a single configuration and single interface.
wrote in message news:xxxxx@ntdev… > Thanks for all the input. > > re the second PID idea, I did ask the question, it did occur to me that > this would be a neat way out of the situation. However, we are developing > this product for > OEM use and one of the strategies is to allow OEMs to program their own > VID/PID pairs, so we are already hamstrung on that one.
OEMs are humans too, they can be convinced. Make few schemes for them to allocate PIDs by pairs (n, n+1) or (n, n+0x100) etc. One driver binary and INF for the main and loader drivers.
Chiming in late here, but another solution is to load usbccgp.sys via
your INF onto the single-interface device–unfortunately I don’t have an
example of how to do this on hand.
Caveat: you might run into an issue like the original one, but on the
devnode representing one of the functions instead of the main device
devnode. If you’re using the same function driver for that interface
before and after firmware then that’s OK. Or, you could add a dummy
first interface to the post-firmware update device, an interface from
which the firmware update driver can determine that the firmware doesn’t
need updating.
On 2/2/2011 9:46 AM, Tim Roberts wrote:
xxxxx@redsoftsys.com wrote:
> I have a USB device that exposes a USB single interface on 1st plug in, then after a firmware download and soft disconnect, exposes 2 USB interfaces.
>
> The problem with this is that on first driver installation, our vendor driver is installed without the underlying composite device driver (usbccgp.sys). When the device is re-enumerated with the 2 interfaces, Windows loads our device driver without first loading usbccgp.sys. The only way to get usbccgp.sys installed is to first uninstall our driver from DevMgr (without unplugging the device), then re-installing the driver. In this case I am able to load a driver for each interface, which is the desired outcome
>
> Is there any way to configure the .inf file to get around this problem?
We actually had a discussion about this very issue last year. There is
no good software solution to this problem. Is this an FX2?
Here are your choices.
Burn your firmware into EEPROM instead of loading it dynamically.
This is the solution I now prefer.
Use a different VID/PID for the non-loaded state. Your “requirement”
that the device use a single PID is probably some misguided marketing
requirement that was produced with no understanding of the technical
issues involved. What, after all, is the downside of using a second
PID? Have you even asked the question?
Modify your unloaded descriptors to include a dummy second
interface. However, if you have this ability, then you can also
implement option 1.
Embed usbccgp.sys’s functionality into your driver, so you become a
bus driver when you detect that the firmware is loaded. That’s ugly.