Questions on USB protocol - Page 1
Forum section: electronics / general

author: promach
author_rank: Frequent Contributor
timestamp: October 09, 2021, 02:14:40 am
content: Fromhttps://www.keil.com/pack/doc/mw/USB/html/_u_s_b__protocol.htmlandhttps://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.

author: ataradov
author_rank: Super Contributor
timestamp: October 09, 2021, 03:52:43 am
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 16, 2021, 12:51:59 pm
content: 4. What do you exactly mean byhubs could have slow single-ended switches that could distort the signal when switching from differential to single-ended mode.?

author: ataradov
author_rank: Super Contributor
timestamp: October 16, 2021, 02:58:43 pm
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 17, 2021, 07:39:12 am
content: 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 ?Quote

author: ataradov
author_rank: Super Contributor
timestamp: October 17, 2021, 07:55:47 am
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 17, 2021, 10:25:56 am
content: QuoteIn Figure 8-14 , it is mentioned that frame size = 1ms , and microframe size = 125us ?

author: ataradov
author_rank: Super Contributor
timestamp: October 17, 2021, 02:25:02 pm
content: That is correct.Why do you need all this info? What is your goal?

author: promach
author_rank: Frequent Contributor
timestamp: October 17, 2021, 03:24:02 pm
content: frame size = 1ms , and microframe size = 125us could not make 3 frames per microframe.

author: voltsandjolts
author_rank: Unknown
timestamp: October 17, 2021, 03:31:39 pm
content: Click here for recommended reading.Quotehttps://beyondlogic.org/usbnutshell/usb3.shtml#USBPacketTypes

author: ataradov
author_rank: Super Contributor
timestamp: October 17, 2021, 04:04:53 pm
content: Quote from: promach on October 17, 2021, 03:24:02 pm"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.

author: promach
author_rank: Frequent Contributor
timestamp: October 17, 2021, 04:26:57 pm
content: I do not understand how is "3 data packets per microframe" being possible at all for high-speed endpoint ?Quote

author: ataradov
author_rank: Super Contributor
timestamp: October 17, 2021, 04:44:42 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 17, 2021, 07:49:44 pm
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 02:58:27 am
content: 2. How do I locate the SOFs or microframe boundaries from the following samples insideVisualUSB?

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 03:12:54 am
content: 3. Why there are ACK and STALL at different timestamp of thefollowing captured waveform?

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 03:26:13 am
content: Quote from: promach on October 18, 2021, 02:58:27 amIt 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 03:30:20 am
content: Quote from: promach on October 18, 2021, 03:12:54 amThe 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).

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 03:48:31 am
content: 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 ?

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 03:57:24 am
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 04:12:20 am
content: 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 fromhttps://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 ?Quote

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 04:13:32 am
content: As for the SOFs or microframe boundaries, I still could not judge anything from the following. Any idea ?

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 04:22:22 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 04:23:22 am
content: Quote from: promach on October 18, 2021, 04:13:32 amWhat do you want to get from them? Here you can see SOF for the frame #1059. This is as much information as you get.

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 09:39:05 am
content: QuoteAccording tohttps://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 ?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 18, 2021, 10:26:08 am
content: > How do I locate the SOFs or microframe boundariesYou need to tick the "Show/Hide SOFs" button. Switching the grouping to "Group transactions" also helps to see lower level details. See the screenshot.

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 10:49:27 am
content: 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 ?

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 02:21:59 pm
content: Quote from: promach on October 18, 2021, 09:39:05 amSETUP 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 02:25:42 pm
content: Quote from: promach on October 18, 2021, 10:49:27 amYou 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 18, 2021, 02:30:15 pm
content: I already checked section 8.6 , but where did you locateThis sequence would start with DATA1.exactly ?

author: ataradov
author_rank: Super Contributor
timestamp: October 18, 2021, 02:39:20 pm
content: 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:QuoteI this is actually makes it consistent with regular (non-control IN/OUT) endpoints.

author: promach
author_rank: Frequent Contributor
timestamp: October 22, 2021, 03:18:36 am
content: How isUSB_REQUEST_PAYLOAD_DATAinside setup stage different from PAYLOAD_DATA inside data stage ?

author: ataradov
author_rank: Super Contributor
timestamp: October 22, 2021, 04:24:00 am
content: 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.

author: Bassman59
author_rank: Super Contributor
timestamp: October 22, 2021, 04:38:40 am
content: Quote from: promach on October 22, 2021, 03:18:36 amRead more of that documentSETUP 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 22, 2021, 08:22:25 am
content: In section 5.9.2 High Bandwidth Isochronous Endpoints , what does it exactly mean by the sentence:For isochronous transactions, if an IN endpoint providesless than a maximumdata payload as specified by its endpoint descriptor, the hostmust not issue further transactionsfor that endpoint for that microframe.?The first part of the sentence seems to contradict with the later part of the sentence ?

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 22, 2021, 09:10:58 am
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 22, 2021, 11:31:07 am
content: May I know why isochronous OUT endpoint is usingMDATAinstead ofDATA2andDATA1?

author: ataradov
author_rank: Super Contributor
timestamp: October 22, 2021, 03:36:00 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 22, 2021, 04:02:36 pm
content: But why OUT is not the same principle as for IN (DATA2, DATA1, DATA0) ?

author: ataradov
author_rank: Super Contributor
timestamp: October 22, 2021, 04:31:31 pm
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 22, 2021, 04:37:35 pm
content: but there is no way to determine which of the twoMDATAtransactions was lost

author: ataradov
author_rank: Super Contributor
timestamp: October 22, 2021, 04:39:26 pm
content: Quote from: promach on October 22, 2021, 04:37:35 pmIt 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 22, 2021, 04:46:40 pm
content: it does not make sense to lose the whole transaction

author: ataradov
author_rank: Super Contributor
timestamp: October 22, 2021, 05:01:29 pm
content: 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.

author: Bassman59
author_rank: Super Contributor
timestamp: October 22, 2021, 07:22:52 pm
content: Quote from: promach on October 22, 2021, 04:46:40 pmIf 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 22, 2021, 07:38:21 pm
content: 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.

author: promach
author_rank: Frequent Contributor
timestamp: October 28, 2021, 01:26:11 pm
content: Why do we need BMC codec ?I tried to readUSB PD 3.0 new BMC decoding circuitarticle, but I am getting more confused.

author: voltsandjolts
author_rank: Unknown
timestamp: October 28, 2021, 01:38:06 pm
content: Well, part of the answer is in the picture you just posted.What would you prefer for fast serial transfer with clock recovery?

author: ataradov
author_rank: Super Contributor
timestamp: October 28, 2021, 04:06:48 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: October 28, 2021, 04:12:25 pm
content: Quote from: SiliconWizard on October 22, 2021, 07:38:21 pmActually 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.Quote from: SiliconWizard on October 22, 2021, 07:38:21 pmLike 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.

author: promach
author_rank: Frequent Contributor
timestamp: November 02, 2021, 03:44:42 am
content: QuoteForUSB 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) ?

author: ataradov
author_rank: Super Contributor
timestamp: November 02, 2021, 04:31:22 am
content: 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?

author: promach
author_rank: Frequent Contributor
timestamp: November 02, 2021, 06:04:41 am
content: QuoteIt seems to be using pull-up in the case of USB Type-CQuoteOn which exact page of USB specification document does this comes from ?

author: ataradov
author_rank: Super Contributor
timestamp: November 02, 2021, 06:18:25 am
content: Quote from: promach on November 02, 2021, 06:04:41 amWhat is using pull-up?Here is a picture of how CCx pins are usedhttps://microchipdeveloper.com/local--files/usb-i:cable-connection/orientation.pngUFP is the device, DFP is the host. As you can see device pulls down those pins.Quote from: promach on November 02, 2021, 06:04:41 amNo 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.

author: promach
author_rank: Frequent Contributor
timestamp: November 02, 2021, 10:07:09 am
content: What is the difference between the two following state diagrams for SINK ?

author: voltsandjolts
author_rank: Unknown
timestamp: November 02, 2021, 10:40:51 am
content: 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.

author: voltsandjolts
author_rank: Unknown
timestamp: November 02, 2021, 10:41:26 am
content: @promachWhat are you trying to achieve?

author: promach
author_rank: Frequent Contributor
timestamp: November 02, 2021, 11:50:56 am
content: In Figure 4-13, what isDebugAccessory.SNKstate for ?

author: promach
author_rank: Frequent Contributor
timestamp: November 03, 2021, 08:14:32 am
content: How do all the followingUSB PD protocol messagesbeing analyzed/decrypted ?

author: ataradov
author_rank: Super Contributor
timestamp: November 03, 2021, 04:50:44 pm
content: This is a strange question. They are decoded according to the USB PD specification.

author: asmi
author_rank: Super Contributor
timestamp: November 03, 2021, 05:23:28 pm
content: Quote from: ataradov on November 03, 2021, 04:50:44 pmThis 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.

author: promach
author_rank: Frequent Contributor
timestamp: November 04, 2021, 06:37:07 am
content: USB PD specalone is not enough,USB Type-C specis also needed.See also theactual decoder coding for sigrokBy the way, may I know where I could locate all the USB DevDays presentation slides across the years ?I only foundhttps://usbpd.wordpress.com/2019/02/07/usb-type-c-pd-presentation-from-usb-developer-days/andhttps://www.scribd.com/document/350194505/Usb-Devdays-Hong-Kong-2016-Usb-Pd

author: voltsandjolts
author_rank: Unknown
timestamp: November 06, 2021, 09:54:53 am
content: @promachI 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.