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.
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. ?
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.
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.
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.
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 ?
That is correct.
Why do you need all this info? What is your goal?
frame size = 1ms , and microframe size = 125us could not make 3 frames per microframe.
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.
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.
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.
2. How do I locate the SOFs or microframe boundaries from the following samples inside
VisualUSB ?
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.
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).
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 ?
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.
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.
As for the SOFs or microframe boundaries, I still could not judge anything from the following. Any idea ?
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.
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.