Device enumeration fails

Hi,
I am having problems getting a certain full speed device to enumerate and
get to the 'load driver' stage on Wince 5.0. The device is recognized and is
usable when connected to my PC. I have used a USB sniffer to look at the
packet traffic and it all seems reasonable.
On the CE host, the device connection is detected and an attachment event is
noticed in the HubStatusChangeThread in the host controller code. It calls
ResetAndEnableHub port which returns OK, but when it tries to get a
descriptor on the default control pipe, the process stalls. It is waiting
for the callback for IssueTransfer and this never gets called.
I am not too familiar with this software or enumeration process... any
suggestions on what can be done, or a where to look to find out more
information?

Jon Hiley

Michel
Sat Apr 26 01:35:23 PDT 2008

What kind of USB device? Is the driver included in the image? Are all
the necessary registry settings on the device? What's the full debug
output of the USB stack with all debug zones on? etc. etc. etc.

Without detailed info or a crystal ball it's very difficult for us to
help you.


Good luck,

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

GuruCE Ltd.
Microsoft Embedded Partner
http://GuruCE.com
Consultancy, training and development services.

hileyj wrote:
> Hi,
> I am having problems getting a certain full speed device to enumerate and
> get to the 'load driver' stage on Wince 5.0. The device is recognized and is
> usable when connected to my PC. I have used a USB sniffer to look at the
> packet traffic and it all seems reasonable.
> On the CE host, the device connection is detected and an attachment event is
> noticed in the HubStatusChangeThread in the host controller code. It calls
> ResetAndEnableHub port which returns OK, but when it tries to get a
> descriptor on the default control pipe, the process stalls. It is waiting
> for the callback for IssueTransfer and this never gets called.
> I am not too familiar with this software or enumeration process... any
> suggestions on what can be done, or a where to look to find out more
> information?
>
> Jon Hiley

hileyj
Mon Apr 28 10:07:01 PDT 2008

Hi,
Thanks for your response. To answer your questions:

> What kind of USB device?
The device is an application development kit for a multi-media processor
(FreeScale i.MX27). It has a mini AB-type full-speed port which I trying to
connect on. The board is running some ROM bootstrapping code upon startup
that enables USB client communications and defines a protocol for configuring
the device. This allows us to download and run an OS image and configure the
board from a PC.

In our product this part will be used primarily as a video codec and will be
hosted by another processor which is running a wince5.0 OS. We would like
the host processor to perform the configuration/image transfer over USB upon
bootup to avoid adding another memory device to the board.

>Is the driver included in the image? Are all
> the necessary registry settings on the device?

Yes, I believe the driver is included and the necessary registry settings
are there. As a test, I placed the reg entry under
HKLM\Drivers\USB\LoadClients\Default\Default\Default\DriverName. The
USBDeviceAttach routine from my driver was called when attaching a keyboard
or mouse.
It doesn't seem as though the enumeration is getting to the point of trying
to find a driver to load.

>What's the full debug
> output of the USB stack with all debug zones on? etc. etc. etc.

Here is some debug output from the HCD common code. There are some
additional messages I put in along with those already in the public code.

+CRootHub::GetStatus - port = 2
-CRootHub::GetStatus - port = 2, returing BOOL 1
+CRootHub::SetOrClearFeature - port = 2, set/clear = 0x1, feature = 0x10
CRootHub::SetOrClearFeature - port = 2, set/clear = 0x1, feature = 0x10,
FAILED
-CRootHub::SetOrClearFeature - port = 2, set/clear = 0x1, feature = 0x10,
returing BOOL 1
-CRootHub::WaitForPortStatusChange, rPort = 2, fSuccess = 1
CHub((NULL) tier 0)::HubStatusChangeThread - port 2, change = 0x0001, status
= 0x0101
+CRootHub::GetStatus - port = 2
-CRootHub::GetStatus - port = 2, returing BOOL 1
CHub((NULL) tier 0)::HubStatusChangeThread - device attached on port 2
CHub: HubStatusChangeThread tier 0 - device attached on port 2
+CHub( tier 0)::AttachDevice - port = 2, fIsLowSpeed = 0
+CDeviceGlobal::ReserveAddress
-CDevice::ReserveAddress, returning rAddress 2, success = 1
CHub::AttachDevice: case DEVICE_CONFIG_STATUS_OPENING_ENDPOINT0_PIPE
CHub::AttachDevice: case DEVICE_CONFIG_STATUS_USING_ADDRESS0
:+CRootHub::ResetAndEnablePort - port = 2
-CRootHub::ResetAndEnablePort - port = 2, returning 1
CHub::AttachDevice: case DEVICE_CONFIG_STATUS_RESET_AND_ENABLE_PORT.

----->I added a 1 sec delay here as I suspected the device wasn't recovering
quickly enough from the port reset.

CHub::AttachDevice: case
DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST.
+CHub((NULL) tier 0)::GetDescriptor - address = 0, Type = 1, Index = 0, Size
= 8
CHub::GetDescriptor: Issued control request.
CDevice::TransferDoneCallbackSetEvent!
CHub::GetDescriptor: Status OK, waiting for hubStatusChangeEvent
CHub::GetDescriptor: fFailed = FALSE
-CHub((NULL) tier 0)::GetDescriptor - address = 0, Type = 1, Index = 0, Size
= 8, returning 1
Setting the device address to 2
CDevice::TransferDoneCallbackSetEvent!
CHub::AttachDevice:
DEVICE_CONFIG_STATUS_SCHEDULING_GET_INITIAL_DEVICE_DESCRIPTOR
+CHub((NULL) tier 0)::GetDescriptor - address = 2, Type = 1, Index = 0, Size
= 8
CHub::GetDescriptor: Issued control request.
CHub::GetDescriptor: Status OK, waiting for hubStatusChangeEvent

Here it stays indefinitely, apparently waiting for the GetDescriptor
transfer to finish. Note that before I added the 1 sec delay, it would fail
in the DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST when trying
for the first time to get a device descriptor.

Jon

hileyj
Thu May 08 11:46:15 PDT 2008

After getting ahold of a USB protocol analyzer, I think I got this one
figured out. The device I was trying to enumerate was not responding as
expected when sending a descriptor request in certain situations. When
asking for a descriptor that was an even multiple of the max packet size on
the control endpoint, the device did not want to ACK in the handshake phase.
Instead the host would keep sending and OUT and zero length data packet, but
the device would continually respond with NAK.
I changed the host controller driver to ask for more than the total size of
the descriptor (ie ask for 33 bytes instead of 32) when it was an even
multiple and set the USB_SHORT_TRANSFER_OK flag in the IssueTransfer call in
GetDescriptor. When I did this, the device would return whatever data it had
(32 bytes for the config descriptor), then would issue a zero length data
packet to indicate the data stage was done. When the host sent the
handshake, the device now responded correctly with an ACK. After this
change, the device enumerated and the driver was loaded correctly.

Paul
Thu May 08 12:01:59 PDT 2008

Have you updated the OS with all of the CE5 QFEs? Seems like someone would
have hit that one before...

Paul T.

"hileyj" <hileyj@discussions.microsoft.com> wrote in message
news:99081088-2226-463D-A4A5-C263D3492D77@microsoft.com...
> After getting ahold of a USB protocol analyzer, I think I got this one
> figured out. The device I was trying to enumerate was not responding as
> expected when sending a descriptor request in certain situations. When
> asking for a descriptor that was an even multiple of the max packet size
> on
> the control endpoint, the device did not want to ACK in the handshake
> phase.
> Instead the host would keep sending and OUT and zero length data packet,
> but
> the device would continually respond with NAK.
> I changed the host controller driver to ask for more than the total size
> of
> the descriptor (ie ask for 33 bytes instead of 32) when it was an even
> multiple and set the USB_SHORT_TRANSFER_OK flag in the IssueTransfer call
> in
> GetDescriptor. When I did this, the device would return whatever data it
> had
> (32 bytes for the config descriptor), then would issue a zero length data
> packet to indicate the data stage was done. When the host sent the
> handshake, the device now responded correctly with an ACK. After this
> change, the device enumerated and the driver was loaded correctly.

hileyj
Thu May 08 14:32:20 PDT 2008

Yes, I'm all QFE'd up. I don't think there's anything wrong with the way the
CE host was acting though... I think the client device wasn't responding
correctly to the descriptor request.

The way I understand it is: if the host asks for more data than is in the
descriptor structure AND the structure is an even multiple of the max packet
size on EP0 then the device should finish the data stage with a zero length
packet. The problem came when the host was asking for the exact size (32
bytes). It got 32 and would try to handshake, but the device would keep
NAKing. When I tried asking for more (33 Bytes) it would send a zero length
at the end and respond to the handshake OK. So it seems as though the client
did not consider the transfer complete or ended up in some weird state when
it didn't send out the 0 length packet, which I believe it shouldn't need to
in this case.

It seems as though the device should know it's sent out all the data needed
and respond to the handshake appropriately.

Jon

"Paul G. Tobey [eMVP]" wrote:

> Have you updated the OS with all of the CE5 QFEs? Seems like someone would
> have hit that one before...
>
> Paul T.
>
> "hileyj" <hileyj@discussions.microsoft.com> wrote in message
> news:99081088-2226-463D-A4A5-C263D3492D77@microsoft.com...
> > After getting ahold of a USB protocol analyzer, I think I got this one
> > figured out. The device I was trying to enumerate was not responding as
> > expected when sending a descriptor request in certain situations. When
> > asking for a descriptor that was an even multiple of the max packet size
> > on
> > the control endpoint, the device did not want to ACK in the handshake
> > phase.
> > Instead the host would keep sending and OUT and zero length data packet,
> > but
> > the device would continually respond with NAK.
> > I changed the host controller driver to ask for more than the total size
> > of
> > the descriptor (ie ask for 33 bytes instead of 32) when it was an even
> > multiple and set the USB_SHORT_TRANSFER_OK flag in the IssueTransfer call
> > in
> > GetDescriptor. When I did this, the device would return whatever data it
> > had
> > (32 bytes for the config descriptor), then would issue a zero length data
> > packet to indicate the data stage was done. When the host sent the
> > handshake, the device now responded correctly with an ACK. After this
> > change, the device enumerated and the driver was loaded correctly.
>
>
>

Paul
Thu May 08 14:45:20 PDT 2008

Does the device fail against a PC running XP, say, also? I'm definitely
making a note of what you found for my reference...

Paul T.

"hileyj" <hileyj@discussions.microsoft.com> wrote in message
news:791C6959-2FF1-457F-9F1B-99930FC51B92@microsoft.com...
> Yes, I'm all QFE'd up. I don't think there's anything wrong with the way
> the
> CE host was acting though... I think the client device wasn't responding
> correctly to the descriptor request.
>
> The way I understand it is: if the host asks for more data than is in the
> descriptor structure AND the structure is an even multiple of the max
> packet
> size on EP0 then the device should finish the data stage with a zero
> length
> packet. The problem came when the host was asking for the exact size (32
> bytes). It got 32 and would try to handshake, but the device would keep
> NAKing. When I tried asking for more (33 Bytes) it would send a zero
> length
> at the end and respond to the handshake OK. So it seems as though the
> client
> did not consider the transfer complete or ended up in some weird state
> when
> it didn't send out the 0 length packet, which I believe it shouldn't need
> to
> in this case.
>
> It seems as though the device should know it's sent out all the data
> needed
> and respond to the handshake appropriately.
>
> Jon
>
> "Paul G. Tobey [eMVP]" wrote:
>
>> Have you updated the OS with all of the CE5 QFEs? Seems like someone
>> would
>> have hit that one before...
>>
>> Paul T.
>>
>> "hileyj" <hileyj@discussions.microsoft.com> wrote in message
>> news:99081088-2226-463D-A4A5-C263D3492D77@microsoft.com...
>> > After getting ahold of a USB protocol analyzer, I think I got this one
>> > figured out. The device I was trying to enumerate was not responding
>> > as
>> > expected when sending a descriptor request in certain situations. When
>> > asking for a descriptor that was an even multiple of the max packet
>> > size
>> > on
>> > the control endpoint, the device did not want to ACK in the handshake
>> > phase.
>> > Instead the host would keep sending and OUT and zero length data
>> > packet,
>> > but
>> > the device would continually respond with NAK.
>> > I changed the host controller driver to ask for more than the total
>> > size
>> > of
>> > the descriptor (ie ask for 33 bytes instead of 32) when it was an even
>> > multiple and set the USB_SHORT_TRANSFER_OK flag in the IssueTransfer
>> > call
>> > in
>> > GetDescriptor. When I did this, the device would return whatever data
>> > it
>> > had
>> > (32 bytes for the config descriptor), then would issue a zero length
>> > data
>> > packet to indicate the data stage was done. When the host sent the
>> > handshake, the device now responded correctly with an ACK. After this
>> > change, the device enumerated and the driver was loaded correctly.
>>
>>
>>

hileyj
Fri May 09 08:38:02 PDT 2008

The device enumerates on my XP PC alright. The difference in the enumeration
that makes it work seems to be:
CE:
1. Get 9 bytes of config descriptor. Use this to determine total length of
interface and endpoint descriptors (32 bytes with my device).
2. Get total length of config descriptor (32).
3. Device sends 4 x 8byte packets then keeps NAKing handshake phase.

PC:
1. Get 9 bytes of config descriptor. Doesn't seem to use this to determine
total length.
2. Just ask for a large amount of config descriptor (255 at first, then 4096
later in the enum process).
3. Device sends 4x8byte packets then a zero length packet, then ACKs
handshake and continues on.

Not sure exactly what the PC is doing during enumeration, I just got this
information from the USB protocol analyzer. I think it's the client device
that's not behaving correctly in this case, maybe this paragraph from the USB
spec was interpretted differently:

"A control pipe may have a variable-length data phase in which the host
requests more data than is contained in the specified data structure. When
all of the data structure is returned to the host, the function should
indicate that the Data stage is ended by returning a packet that is shorter
than the MaxPacketSize for the
pipe. If the data structure is an exact multiple of wMaxPacketSize for the
pipe, the function will return a zero-length packet to indicate the end of
the Data stage."

I believe the last sentence should only apply IF you request more than the
structure size, but it seems as though the client device is applying it even
when you request the exact size.

Jon
"Paul G. Tobey [eMVP]" wrote:

> Does the device fail against a PC running XP, say, also? I'm definitely
> making a note of what you found for my reference...
>
> Paul T.

Paul
Fri May 09 09:53:06 PDT 2008

Thanks for the data. It sounds like the device was never tested in the
specific environment you're operating in (CE's USB stuff), and, yes, it's
probably wrong. It's too bad that there isn't a closer match in the
behavior with the desktop, since that's what every device manufacturer is
going to test with.

Paul T.

"hileyj" <hileyj@discussions.microsoft.com> wrote in message
news:AD26512F-D435-43E1-9854-DB7A98AA5EF7@microsoft.com...
> The device enumerates on my XP PC alright. The difference in the
> enumeration
> that makes it work seems to be:
> CE:
> 1. Get 9 bytes of config descriptor. Use this to determine total length
> of
> interface and endpoint descriptors (32 bytes with my device).
> 2. Get total length of config descriptor (32).
> 3. Device sends 4 x 8byte packets then keeps NAKing handshake phase.
>
> PC:
> 1. Get 9 bytes of config descriptor. Doesn't seem to use this to determine
> total length.
> 2. Just ask for a large amount of config descriptor (255 at first, then
> 4096
> later in the enum process).
> 3. Device sends 4x8byte packets then a zero length packet, then ACKs
> handshake and continues on.
>
> Not sure exactly what the PC is doing during enumeration, I just got this
> information from the USB protocol analyzer. I think it's the client
> device
> that's not behaving correctly in this case, maybe this paragraph from the
> USB
> spec was interpretted differently:
>
> "A control pipe may have a variable-length data phase in which the host
> requests more data than is contained in the specified data structure.
> When
> all of the data structure is returned to the host, the function should
> indicate that the Data stage is ended by returning a packet that is
> shorter
> than the MaxPacketSize for the
> pipe. If the data structure is an exact multiple of wMaxPacketSize for
> the
> pipe, the function will return a zero-length packet to indicate the end of
> the Data stage."
>
> I believe the last sentence should only apply IF you request more than the
> structure size, but it seems as though the client device is applying it
> even
> when you request the exact size.
>
> Jon
> "Paul G. Tobey [eMVP]" wrote:
>
>> Does the device fail against a PC running XP, say, also? I'm definitely
>> making a note of what you found for my reference...
>>
>> Paul T.