xxxxx@gmx.de wrote:
we’re starting development of a new project, a USB 2.0 device. The project contains
both the KMDF device driver and the device’s firmware.
We’ve defined the number of endpoints, but we expect that we have to increase the
number of used endpoints during lifetime of the device to meet new requirements,
but we don’t know type or exact number.
At what point do you expect to know that? This is a very unusual
requirement. The endpoints encapsulate the very functionality of the
device. If the endpoints change, you usually need a different driver to
handle them, which means a re-enumeration.
What kind of a device is this?
Here our question is if the device configuration descriptors may change during
enumeration?
I’m not sure what you mean by “during enumeration”. The operating
system is permitted to cache your configuration descriptor after it
reads it, and not re-read it again until the device unplug and replugs,
or gets reset.
On the device we have a ROM-based bootcode, exporting the USB device
configuration consisting of two configuration descriptors; this bootcode can’t be
modified at the customer. Later on a firmware is downloaded by the driver, using
this second USB configuration; this firmware can be modified at the customer by
a driver update. Is it allowed / possible that the firmware’s configuration
descriptor differs (different endpoint number, type, …) from the one reported
by bootcode?
No. If you change your configuration descriptor, you need to
re-enumerate. The host controller driver has to create a set of tables
with an entry for each endpoint. If you device has endpoints that were
not reported in the configuration descriptor, those tables will not have
been created. There will not be a pipe handle, and drivers will not be
able to access it.
We basically know the approach of a second enumeration (see WDK “Configuring USB
Devices that Require Firmware Downloads”,
http://msdn.microsoft.com/en-us/library/ff537061(v=VS.85).aspx), but we’d like
to avoid the mentioned problems, especially regarding PowerManagement.
I think you need to read that document again, because it does not affect
your situation. If your on-the-fly firmware is transient (meaning it is
not burned into EEPROM), then it doesn’t matter how you handle the new
descriptors. When the USB hub turns off your power, the transient
firmware will be lost, and you’ll go back to whatever was programmed in
the EEPROM. But if the on-the-fly firmware is burned into EEPROM as
part of the driver update (as I would expect), then all is well. You’ll
power up with the new firmware, and you will re-enumerate.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.