1
\$\begingroup\$

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.

enter image description here

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
\$\endgroup\$
2
\$\begingroup\$

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:

enter image description here

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.

\$\endgroup\$
  • \$\begingroup\$ I think the Total Phase Data Center is lying to me - for my convenience. It is taking the data payload from the DATA1 #14 response and putting it 'as a summary' in the byte dump for the overall Get Device Descriptor #6 as well as #11 IN transaction \$\endgroup\$ – Jason Pyeron Oct 8 '18 at 13:16
  • \$\begingroup\$ Thanks for the recommendation on store.teledynelecroy.com/collections/usb-solutions , but they are not cheap for my personal project. \$\endgroup\$ – Jason Pyeron Oct 8 '18 at 13:19
  • \$\begingroup\$ @JasonPyeron, it looks like normal hierarchical representation of transactions, the trace display just shows naked data at the transaction level (line #11), and expands all data after expansion the transaction into packet level, where all tokens are shown (lines 13, 14, 15). So everything is correct. \$\endgroup\$ – Ale..chenski Oct 8 '18 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.