Questions on USB protocol

[promach]

From https://www.keil.com/pack/doc/mw/USB/html/_u_s_b__protocol.html and https://github.com/sigrokproject/sigrok-dumps/tree/master/usb/setup , I have few questions:

1. Why there are two different pipes labelled as 1 and 2 ?

2. What does it mean by 8 microframes of 125us ?

3. Why the usb_failed_setup_fullspeed.sr waveform being a failed setup ?

4. I do not quite understand the dribble mechanism in section 7.1.9.1 of usb2.0 specification document.

[ataradov]

1. It just shows that in a single frame there may be communication with multiple devices or sub-devices withing the same device. From the host perspective they are pipes. From the device - endpoints.
2. In HS planing intervals (frames) are 8 times shorter and are called micro-frames. It does not change much as far as actual operation goes, 1 ms was just too long for high speeds.
3. Edited my response. It is incorrect. Let me figure out what is actually going on. It still looks like there was a STALL response at some point, but it is not shown here.
4. No idea if this will ever happen in practice with modern hardware. This was written in times when HS did not exist and hubs could have slow single-ended switches that could distort the signal when switching from differential to single-ended mode.

[promach]

4.  What do you exactly mean by hubs could have slow single-ended switches that could distort the signal when switching from differential to single-ended mode. ?

[ataradov]

Normal communication is differential - D+ and D- switch at the same time. The bit value is determined by the difference. When EOP is signaled, both lines go low. Which means that one of the lines has to stay low, and the other one will have to switch from high to low. This transition from differential to single ended mode may change bit timings.

Again, this has not been a problem for 20+ years in real life, this is just a leftover from very early days of the standard, but they can't just remove things.

[promach]

2.  Check section 8.4.3.1 USB Frames and Microframes inside USB 2.0 specification.

Could you comment a bit more about 5.9 High-Speed, High Bandwidth Endpoints with regards to the microframe ?

USB supports individual high-speed interrupt or isochronous endpoints that require data rates up to
192 Mb/s (i.e., 3072 data bytes per microframe). One, two, or three high-speed transactions are allowed in
a single microframe to support high-bandwidth endpoints.

[ataradov]

What specifically is not clear here?

Normally you are allowed one frame per endpoint per microframe.  With high-bandwidth endpoints you can send up to 3 frames per microframe. This gives the device more bandwidth at the expense of other devices.

[promach]

With high-bandwidth endpoints you can send up to 3 frames per microframe.

In Figure 8-14 , it is mentioned that frame size = 1ms , and microframe size = 125us  ?

[ataradov]

That is correct.

Why do you need all this info? What is your goal?

[promach]

 frame size = 1ms , and microframe size = 125us   could not make   3 frames per microframe.

[voltsandjolts]

Click here for recommended reading.

The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus.

https://beyondlogic.org/usbnutshell/usb3.shtml#USBPacketTypes

[ataradov]

frame size = 1ms , and microframe size = 125us   could not make   3 frames per microframe.

"3 data packets per microframe" is more correct. Sorry, it was late.

Frames and microframes are fixed, they never change regardless of the number of devices on the bus or data flow. They are separated by SOF packets. Between the SOF packets there are data packets. And normally you can only send one packet from each endpoint. With high-bandwidth endpoints you can have 3.

[promach]

I do not understand how is "3 data packets per microframe" being possible at all for high-speed endpoint ?

USB supports individual high-speed interrupt or isochronous endpoints that require data rates up to
192 Mb/s (i.e., 3072 data bytes per microframe). One, two, or three high-speed transactions are allowed in
a single microframe to support high-bandwidth endpoints.

[ataradov]

It just sends 3 data packets after one SOF packet. Why would it be hard?

The whole protocol is a series of data packets between the SOF packets. You can have as many data packets as will fit in the allocated time.

That picture with just one packet between the SOF packets is misleading. There will dozens or hundreds of them.

[abyrvalg]

You can study real low level traffic samples bundled with hw USB analyzer’s software, i.e. https://ellisys.com/products/download/visualusb.msi. Unfiltered samples contain SOFs, so you’ll be able to see microframe boundaties.

[promach]

2. How do I locate the SOFs or microframe boundaries from the following samples inside VisualUSB ?

[promach]

3. Why there are ACK and STALL at different timestamp of the following captured waveform ?

[ataradov]

2. How do I locate the SOFs or microframe boundaries from the following samples inside VisualUSB ?

It looks like they have been filtered out. This is a very typical thing to do, since they will overwhelm your log. Not sure if they are filtered for display only or during the capture. I'm not familiar with that software.

You can get a rough idea from the timestamps though.

Also, you can try to open IN/OUT/SETUP transactions further. SOFs may be hidden there.

[ataradov]

3. Why there are ACK and STALL at different timestamp of the following captured waveform ?

The screenshots here do not show full transfer. You see setup packet with some data, which got acknowledged in both cases. But then (depending on the request type from that data packet, for example) device responded with ACK or STALL. This happens later than what is shown here. You need to zoom out until you see a complete "USB request: USB SETUP" line. This will be the full request.

In the summary (in "USB request: USB SETUP") you can  see that in the second case there was some data sent in response. In the first case there is no data (empty brackets).

[promach]

When I tried to zoom out, I do not see any [ 09 02 29 00 01 01 00 80 32 ] before 2250us, so where does this data segment come from ?

[ataradov]

It is somewhere  in the last section of this screenshot. Somewhere in the range covered by the last segment labeled "USB request: USB SETUP". Look closer towards the end.

Most likely there will be a long sequence of SETUP/NAK transfers, which will end with SETUP/ACK. Right before the ACK there will be your data.

[promach]

It is at 3470us.

What confuses me is that why USB request field requires two separate segments of data as in why two separate square brackets containing DATA0 and DATA1 respectively in order to transition from STALL to ACK status ?

As quoted from https://www.usbmadesimple.co.uk/ums_7.htm , can I assume that the usb device will send STALL status to the HOST as a waiting signal for DATA1 since only DATA0 is received so far ?

DATA0 and DATA1 PIDs are used in Low and Full speed links as part of an error-checking system. When used, all data packets on a particular endpoint use an alternating DATA0 / DATA1 so that the endpoint knows if a received packet is the one it is expecting. If it is not it will still acknowledge (ACK) the packet as it is correctly received, but will then discard the data, assuming that it has been re-sent because the host missed seeing the ACK the first time it sent the data packet.

[promach]

As for the SOFs or microframe boundaries, I still could not judge anything from the following.  Any idea ?

[ataradov]

As the standard says, DATA0/1 are used for error checking. After the bus reset or SETUP transfer (and a few other cases too), toggle bit resets to 0. And it toggles with each frame sent by either side. Both host and device keep track of this bit. If a frame went missing, then either side would be able to detect it.

If I understand correctly what you mean by brackets, then it is just a request and response. For the request part of the SETUP transfer host will always send DATA0. Device will respond with its current toggle state. The fact that it is DATA1 here is just a coincidence. Although I'm actually not 100% sure, setup might reset the toggle both for both directions for the control endpoint. I'm too tired to check the spec.

Ok, yes, DATA stage of the control transfer would always start with DATA1, and setup stage with DATA0. As usual, control endpoint is not like other endpoints and does its own thing.

Section 8.6 "Data Toggle Synchronization and Retry" describes this part and shows examples of how error recovery works using those toggle bits.

Note that toggle bits are separate for the host and device (and generally they are separate for each endpoint/pipe), so both devices need to keep track of both bits - own and from the other side. And again, the algorithms of how they are reset and toggled are described in the spec.

[ataradov]

As for the SOFs or microframe boundaries, I still could not judge anything from the following.  Any idea ?

What do you want to get from them? Here you can see SOF for the frame #1059. This is as much information as you get.

[promach]

DATA stage of the control transfer would always start with DATA1, and setup stage with DATA0.

According to https://www.beyondlogic.org/usbnutshell/usb3.shtml#USBPacketTypes , it seems that setup token packet is used to begin control transfers, and your quoted sentence above contradicts with the specification ?

[abyrvalg]

> How do I locate the SOFs or microframe boundaries
You need to tick the "Show/Hide SOFs" button. Switching the grouping to "Group transactions" also helps to see lower level details. See the screenshot.

[promach]

Thanks for the tips on Ellisys USB analyzer software.

May I know if it is possible at all to automatically export/transform the series tabular information about the USB transactions into parallel waveform signals for easier visual observation ?

[ataradov]

DATA stage of the control transfer would always start with DATA1, and setup stage with DATA0.

According to https://www.beyondlogic.org/usbnutshell/usb3.shtml#USBPacketTypes , it seems that setup token packet is used to begin control transfers, and your quoted sentence above contradicts with the specification ?

SETUP token is used to start the control transfer, but the token itself does not carry any data. Control transfer has setup and data stages. Setup stage is the SETUP+DATA0+ACK tokens/packets. Then the data stage is zero or more DATAx packets. This sequence would start with DATA1.

All this is shown in the section of the standard I mentioned earlier.

The terminology of USB is very confusing and in casual conversation is not easy to always get right without a lot of additional words. You have to read the standard to understand what all those terms mean and how they all relate.

[ataradov]

May I know if it is possible at all to automatically export/transform the series tabular information about the USB transactions into parallel waveform signals for easier visual observation ?

You mean export into something like your logic analyzer traces? I don't think it is possible with any of those tools. It is not easier. Once you start looking at high level protocols, that logic analyzer view will turn into a complete mess.

The way USB analyzers represent things today is not bad for practical uses.

[promach]

I already checked section 8.6 , but where did you locate This sequence would start with DATA1. exactly ?

[ataradov]

There is a picture in the section 8.6.1 "Initialization via SETUP Token". And in the followup pictures.

With words and even more pictures it is explained in details in the section 8.5.3 "Control Transfers".

Also, it looks like the status stage (last stage in the transfer) always uses DATA1 regardless of the state of the toggle bit:

A Status stage is delineated by a change in direction of data flow from the previous stage and always uses a DATA1 PID. If, for example, the Data stage consists of OUTs, the status is a single IN transaction. If the control sequence has no Data stage, then it consists of a Setup stage followed by a Status stage consisting of an IN transaction.

I this is actually makes it consistent with regular (non-control IN/OUT) endpoints.

[promach]

How is USB_REQUEST_PAYLOAD_DATA inside setup stage different from PAYLOAD_DATA inside data stage ?

[ataradov]

Yes, it is different. SETUP stage has a fixed format that contains a request type. This part is always 8 bytes in size. This for example can be a string descriptor request that includes the string index. The data stage is the actual data that was requested - in this example the string value. This part is variable in length (including 0 bytes). This part can also span multiple frames. Maximum control endpoint transfer size is 64 bytes, and device descriptors for complex device can easily be bigger than this.

Format of the setup stage request is this:

  uint8_t   bmRequestType;
  uint8_t   bRequest;
  uint16_t  wValue;
  uint16_t  wIndex;
  uint16_t  wLength;

You will see it everywhere, as this is the first thing you face when dealing with USB on a software level.

[Bassman59]

How is USB_REQUEST_PAYLOAD_DATA inside setup stage different from PAYLOAD_DATA inside data stage ?

Read more of that document

SETUP packets are used in control transactions on Endpoint 0. It's how USB requests are sent from the host to the device. A SETUP transfer might be able to send all of the necessary information for the control transfer in the 8-byte payload for the SETUP.  If necessary then more data can be sent in a DATA state for the SETUP transfer.

The other endpoints don't have a SETUP stage, but they do have DATA packets.

In the end, what happens is that your micro gets an interrupt saying "you have data" and you have to figure out what endpoint interrupted you so you know what to do with your data.

[promach]

In section 5.9.2 High Bandwidth Isochronous Endpoints , what does it exactly mean by the sentence: For isochronous transactions, if an IN endpoint provides less than a maximum data payload as specified by its endpoint descriptor, the host must not issue further transactions for that endpoint for that microframe. ?

The first part of the sentence seems to contradict with the later part of the sentence ?

[abyrvalg]

Each EP has a maximum packet size (advertised in config descriptor, so host knows it). If in response to an IN token the device sends less than that maximum - it indicates to host that device has no more data ready to send right now. Looks logical - if you have more data than MaxPacketSize - send the maximum, and if you are sending less than maximum - you have less than maximum and it is useless to ask you to send more immediately, see you in the next frame.

The same mechanism is used on bulk endpoints to indicate end of transfer - the last packet is either short (less than EP.MaxPacketSize) or a ZLP (zero-lenght packet) if the total transfer size is a multiple of MaxPacketSize.

[promach]

May I know why isochronous OUT endpoint is using MDATA instead of DATA2 and DATA1 ?

[ataradov]

For the IN transfer the first packet indicates how many more to follow. If the host receives DATA2, it knows it has to issue two more IN tokens.

For the OUT transfers DATAx indicates end of transfer. The device must count how many MDATA packets were received to check the whole transaction.

This is basically due to asymmetrical nature of the USB - host always drives the communication.

[abyrvalg]

But why OUT is not the same principle as for IN (DATA2, DATA1, DATA0) ?

[ataradov]

Because now if device receives DATA2 right away it will discard that packet, since there were no 2 MDATA packets before that, so the whole transaction is invalid.

If you start with DATA2, you will not have this control.

The goal here is to ensure that all 3 packets are received, and if one is missing, then the remaining should be discarded too.

In both cases highest DATAx indicates how many packets were supposed to be in the transfer.

[promach]

but there is no way to determine which of the two MDATA transactions was lost

[ataradov]

but there is no way to determine which of the two MDATA transactions was lost

It does not matter. It is isochronous transfer - if things are lost, they are lost. There is no retry mechanism anyway, so knowing what specifically is lost would not help.

The goal is to lose the whole transaction and not just one packet, as higher level protocols may rely on that property. But those protocols would be tolerant to the loss of the whole transaction.

[promach]

it does not make sense to lose the whole transaction

[ataradov]

It does. Higher level protocols rely on that. They may put a single video frame header in the first packet and raw frame data in the rest of them. If you lose the first one your whole protocol will be de-synchronized. If you lose all 3, then all you've lost is a single frame of video. This is just a very trivial example where losing the whole thing is better than losing just one part.

People that designed USB are not stupid, they knew what they were doing. So a better approach is to try to understand why something was done one way or the other instead of criticizing it.

[Bassman59]

it does not make sense to lose the whole transaction

If your system design allows for it, you can use bulk or interrupt transfers instead of isochronous. Those two transfers allow for retries in the event that those host "loses" something.

Although I don't know what would cause the host to lose data in a way it can manage. USB uses a host-to-device direct connection (maybe a hub in between) and the host "knows" what bandwidth is available. It won't allow transfers if it can't handle them. The usual failure mode is a bad cable, and no protocol overhead in the world can work around that.

[SiliconWizard]

Yes. As a note, do NOT use isochronous transfers unless you really really really... have to. They're usually a waste of bandwidth and as said above, there is no guarantee of data delivery.

A number of "streaming"-like applications can successfully use bulk transfers as long as you buffer data properly.

[promach]

Why do we need BMC codec ?

I tried to read USB PD 3.0 new BMC decoding circuit article, but I am getting more confused.

[voltsandjolts]

Well, part of the answer is in the picture you just posted.
What would you prefer for fast serial transfer with clock recovery?

[ataradov]

Clock recovery is the primary goal. For reliable communication at fast speeds you either need a separate clock or a highly accurate clock source on both sides. Or you can use protocol with encoding that allows for clock recovery.

Manchester code is one of the earlier examples of such encoding. Even in regular USB communication you see bit stuffing (prevention of long runs of 1s or 0s), which lets devices recover the bit timing.

PD is oriented at low cost implementations, so Manchester code is a good idea.

[asmi]

Yes. As a note, do NOT use isochronous transfers unless you really really really... have to. They're usually a waste of bandwidth and as said above, there is no guarantee of data delivery.

Actually pretty much all applications which need to work with real-time data will have to deal with situation when there is a snag with input data delivery for whatever reason. And buffering is not always an option - for example if latency is critical. Isochronous transfers guarantee bandwidth allocation as they are always executed first in the (micro-)frame.

A number of "streaming"-like applications can successfully use bulk transfers as long as you buffer data properly.

Like I said above, buffering is not always an option. And it's not that hard to use isochronous transfers, but you will have to understand how it works. Like the video example above, in many cases you can interpolate or just guess what missing data was, and design your application around that.

[promach]

When a port determines that the locally-inserted plug is flipped (i.e. CC1 is open, CC2 is terminated), the USB4 Specification (reference Sideband Channel Lane Reversal) dictates that the port flip the SBTX and SBRX mappings to SBU1 and SBU2 in order to assure proper sideband transmit-to-receive end-to-end operation.

For USB type-C specification, how is CC1 being opened, and CC2 being terminated considered as flipped plug ?
and why do we need Sideband Use (SBU1 and SBU2) ?

[ataradov]

I don't understand the question. Device always terminates (pulls down) CC1 and CC2 pins. The cable will only carry one of them to the host and terminate the other one to the ground. This way both sides can determine the orientation of the cable and switch the data lines accordingly.

This is only necessary for SuperSpeed stuff. Legacy LS/FS/HS lines are switched automatically because they are shorted on the PCB. But this means you need two times more pins. For SS they decided to have 4 independent links (2 TX, 2 RX), which requires cable orientation detection and corresponding multiplexing of the TX/RX lines.

SBUx are just low speed channels that are not even necessarily used for data. They may be used to carry audio or some UART stuff. They are just additional pins that are defined by the higher level protocols. By default they don't do anything.

Why do you need all of this? What is your goal?

[Trader]

[promach]

Device always terminates (pulls down) CC1 and CC2 pins.

It seems to be using pull-up in the case of USB Type-C

For SS they decided to have 4 independent links (2 TX, 2 RX), which requires cable orientation detection and corresponding multiplexing of the TX/RX lines.

On which exact page of USB specification document does this comes from ?

[ataradov]

It seems to be using pull-up in the case of USB Type-C

What is using pull-up?

Here is a picture of how CCx pins are used https://microchipdeveloper.com/local--files/usb-i:cable-connection/orientation.png

UFP is the device, DFP is the host. As you can see device pulls down those pins.

On which exact page of USB specification document does this comes from ?

No idea, I have not read the USB3 spec. I just read the summaries and that was enough for my use. It also makes sense from the way USB3 connectors are typically routed.

[promach]

What is the difference between the two following state diagrams for SINK ?

[voltsandjolts]

You should probably ignore the Debug and Test System stuff until you have a functional USB-C device.
And then perhaps continue to ignore it.

[voltsandjolts]

@promach

What are you trying to achieve?

[promach]

In Figure 4-13, what is DebugAccessory.SNK state for ?

[promach]

How do all the following USB PD protocol messages being analyzed/decrypted ?

[ataradov]

This is a strange question. They are decoded according to the USB PD specification.

[asmi]

This is a strange question.

This whole thread is full of strange questions. I'm still at a loss what TS is trying to achieve asking all those questions which can be answered by just reading the spec.

[promach]

USB PD spec alone is not enough, USB Type-C spec is also needed.

See also the actual decoder coding for sigrok


By the way, may I know where I could locate all the USB DevDays presentation slides across the years ?

I only found https://usbpd.wordpress.com/2019/02/07/usb-type-c-pd-presentation-from-usb-developer-days/ and https://www.scribd.com/document/350194505/Usb-Devdays-Hong-Kong-2016-Usb-Pd

[voltsandjolts]

@promach
I see you also post a lot of questions in a similar style (non-interactive, limited feedback, spoon-feeding requests) here, including repeats of some of these usb questions. It's all a bit weird. I'm out.