String enumeration problem

[lpcware]

Content originally posted in LPCWare by mubes on Fri May 23 16:18:53 MST 2014
Folks,

I'm having a spot of bother with device enumeration on Linux (The device is a LPC1549 and the usb stack is my own).  This is a composite device with both a MSC and CDC in it, but I'm not too sure that's important.  The issue is that when the enumeration process is collecting the strings from the device it grabs the strings, then asks for the first two characters of each string (beyond the first three) again...with the result that it times out after five seconds before going through the whole thing again for the next one...as shown below;

No.Time        Source  DestProtLenInfo
727.2591788hostUSB80GET DESCRIPTOR Response STRING
737.259205host8USB64GET DESCRIPTOR Request STRING
7412.2591598hostUSB64GET DESCRIPTOR Response STRING[Malformed Packet]
7512.259261host8USB64GET DESCRIPTOR Request STRING
7617.2591628hostUSB80GET DESCRIPTOR Response STRING
7717.259203host8USB64GET DESCRIPTOR Request STRING
7822.2591668hostUSB64GET DESCRIPTOR Response STRING[Malformed Packet]
7922.259237host8USB64GET DESCRIPTOR Request STRING
8027.2591648hostUSB82GET DESCRIPTOR Response STRING
8127.259178host8USB64GET DESCRIPTOR Request STRING
8232.2592498hostUSB64GET DESCRIPTOR Response STRING[Malformed Packet]

The first three strings it grabs perfectly well.  Is this normal and I'm not understanding something or is something 'interesting' going on with the Linux driver (Kernel 3.11.0)?  I can see the wLength in the request set to '2' for the second request (it's set to 255 for the first request of each pair) so I think this is originating from the host side as opposed to the device side.

I will try again in the morning with a Mac and windows box, but since I don't have wireshark on those it makes life a bit more complex.

Thanks in advance for any light on this...

DAVE

[lpcware]

Content originally posted in LPCWare by mubes on Sun May 25 11:38:32 MST 2014
Tsuneo,

Yes, I have to admit I'm still slightly confused why this has fixed things, since the debug packets were short (and thus nowhere near the timeout periods) and, more importantly, the -entire- message appeared to have been received by the host with the length-2 request only being generated after a 5 second timeout.  In the URB there was an error status set in the full length packet reception which implied that the reception had been terminated by timeout rather than by complete message reception, so my working assumption is that some short-timer in the kernel was tripped that invalidated the end of message indication and then the length-2 retransmit was triggered after the timeout.

Oh well, it's all good learning  :bigsmile:

Regards

Dave

[lpcware]

Content originally posted in LPCWare by Tsuneo on Sun May 25 10:47:18 MST 2014

---

Quote:
Removing the debug output seems to have fixed the problem.

---

Ah, debug output often causes timeout on the host to process Control Transfer.
Also, this timeout is the reason why debug stepping through disturbs host enumeration sequence.
USB2.0 spec defines the timeout on Control transfer in this chapter.

9.2.6.4 Standard Device Requests

For standard device requests that require data stage transfer to the host (ie. Control Read transfer), the device must be able to return the first data packet to the host within 500 ms of receipt of the request. For subsequent data packets, if any, the device must be able to return them within 500 ms of successful completion of the transmission of the previous packet. The device must then be able to successfully complete the status stage within 50 ms after returning the last data packet.

Tsuneo

[lpcware]

Content originally posted in LPCWare by mubes on Sat May 24 15:27:44 MST 2014
OK, found it.  Removing the debug output seems to have fixed the problem.  It was running at 115K and it seemed to be working fine for the rest of the init sequence, but I guess it was just taking too much time and breaking the protocol during the string transfers.  More testing to be done, but it's certainly not borking in the same ways any more.

Regards

DAVE

[lpcware]

Content originally posted in LPCWare by mubes on Sat May 24 12:47:30 MST 2014
Tsuneo,

Thanks for your rapid reply (and indeed, for your contribution to the community understanding of USB, I see your footprints in many places across the 'net).  The problem is that I have several other transactions that would result in a ZLP and those are all completing correctly...also, I changed the length of the strings in question to avoid the ZLP/ZLT arising and I'm afraid it didn't really change the situation;

69*REF*        host7USB64GET DESCRIPTOR Request STRING
704.9986067hostUSB82GET DESCRIPTOR Response STRING
714.998648host7USB64GET DESCRIPTOR Request STRING
729.9986527hostUSB64GET DESCRIPTOR Response STRING[Malformed Packet]
739.99891        host7USB64GET DESCRIPTOR Request STRING
7414.9986137hostUSB82GET DESCRIPTOR Response STRING
7514.998657host7USB64GET DESCRIPTOR Request STRING
9219.9985427hostUSB64GET DESCRIPTOR Response STRING[Malformed Packet]
9319.998622host7USB64GET DESCRIPTOR Request STRING
13424.9985997hostUSB84GET DESCRIPTOR Response STRING
13524.998643host7USB64GET DESCRIPTOR Request STRING
17629.998647hostUSB64GET DESCRIPTOR Response STRING[Malformed Packet]

I'm a little bit stumped at the moment....I guess I'm upsetting the string receiver at the Linux end somehow, but I don't really know how. I'll post again when I get to the bottom of this.

DAVE

[lpcware]

Content originally posted in LPCWare by Tsuneo on Sat May 24 08:54:51 MST 2014
Device stack responds to Get_Descriptor request as follows,

a) wLength <= specified descriptor size
Device stack returns just the first wLength bytes of the descriptor at the DATA stage.

b) wLength > specified descriptor size
Device stack returns entire descriptor (without any padding) at the DATA stage.
When the descriptor size is just a multiple of bMaxPacketSize0 (EP0 max packet size),
the Data stage is terminated by ZLT (Zero-Length Transaction, same as ZLP)

This behavior is common to the process of Control Read Transfer.
You may integrate this behavior at Control Read Transfer layer of your stack.

Tsuneo