While tracing the USB using a Beagle 12, I am sometimes finding bytes prior to the transaction start. It is not the 8/32 bit SYNC, it does not start with a PID (e.g. 0x12 is 00010010b and a PID is ABCDa̅b̅c̅d̅) I am having troubl digesting section 8 of the USB 2.0 SPEC, and section 9 does not seem to address data prior to the PID.
What are these bytes for?
12 01 00 02 00 00 00 20
E6 04 16 51 04 03 01 02
00 01
Setup transaction:
80 06 00 01 00 00 40 00
Setup packet:
2D 00 10
get device descriptor:
C3 80 06 00 01 00 00 40
00 DD 94
ACK:
D2
Best Answer
These bytes are the descriptor data returned by your device in response to GET_DESCRIPTOR request. These data can't appear before the start of control transfer, something is missing in your observation.
The host must start with SETUP transaction [2D]. Then the setup data should follow:
[C3] is DATA0 token, [80 06 00 01 00 00 40 00] is "get descriptor", [DD 94] is CRC16.
This SETUP token must have ACK from your device.
The host then should proceed with IN token.
The device, in response to IN token [69], should always return the result, which is [12 01 00 02 ........]
"12" means that the descriptor contains 18 bytes of data. The rest you would need to decode, preferably using a better tool, like Teledyne-LeCroy/CATC decoder.
In particular, bytes[8..9] [E6 04] mean the Vendor ID = 0x04E6 (
SCM Microsystems), the next 2 bytes [16..51] means PID=0x5116 - product iD (SCR3310 SmartCard Reader), the rest are other standard fields of your device descriptor.
[D2] is ACK, which is good.
Here is an example of GET_DESCRIPTOR transfer from a LS mouse:
The descriptor data (18 bytes) are split by host into 3 transactions, because of max_packet_size is 8 bytes only for this particular device (Logitech mouse). The whole transfer also has several NAKed transactions, which are hidden.