Hi chip experts,
According with USB specification, up to 127 Devices could be connected to a single Host.
However, there are some bandwidth restrictions for interrupt and isochronous transfer types.
If the bandwidth limit is reached, no more Devices with the same requirements could be enumerated.
So I tried to evaluate 7 USB devices which can communicate with one host controller or not.
Please see attached.
Details:
Transfer mode = Interrupt/IN only
Transfer period = 2ms
OS = T-kernel RTOS
Protocol/USB class = original/original
Data size = 256/512/1024 byte
In case of 256 byte or 512 byte of data packet size, we confirmed it was OK and there were all 7 IN transactions in 1 uFrame.
But in case of 1024 byte, there were only 5 IN transactions in 1 uFrame. I guess the bandwidth limit is reached and
2 of IN transactions lost. I expected next transactions include missing 2 but I couldn't find them.
Are there any restrictions related to Host controller?
Can anyone explain about above behavior?
Thanks.
Dear YeXian,
Thank you for your reply.
I guess uSDHC IP didn't support to reschedule exceed packets sending, so SW should treat of them.
Let me clarify several things.
- Does uSDHC IP surprisingly support above feature?
- If yes, how to configure it?
- If not, SDHC driver of linuxBSP support following features?
a. move the 2 packet to the next micro-frame
b. reject the up-layer request
- Is there any documents or sample codes to implement above features?
- Is it possible to specify few packets move to the next frame?
Our goal is communicate with 8 USB devices. Let me update the diagrams(see below).
I'll appreciate your any help.
Best Regards.
---
.png "Employee")
Q1
About "If yes, in our case there were 7 devices and corresponding 7 endpoints which scheduled sending within one microframe by setting S-mask field in the Queue Head, then it maybe caused bandwidth shortage although it depends on the data size." What do you mean?
As per specification, If the queue head is for an interrupt endpoint (for example, non-zero S-mask field), then the FRINDEX[2:0] field must identify a bit in the S-mask field that has one in it. For example, an S-mask value of 00100000b would evaluate to true only when FRINDEX[2:0] is equal to 101b. If this condition is met then the host controller considers this queue head for a transaction. So, you can change QH S-mask to distribute 7 Interrupt IN transactions into different uframes instead of only one uframe.
Q2
It is not overflow but Micro-Frame Integrity mechanism.
As per specification, the HC must ensure that it does not start transactions that will not be completed before the end of the micro-frame. More precisely, no transactions should be started by the host controller, which cannot be completed in their entirety before the EOF1 point. In order to enforce this rule, the host controller must check each transaction before it starts to ensure that it will complete before the end of the micro-frame.
So, When bandwidth limit is reached, remaining QH in the same uFrame will be dropped and start next uFrame. If you don't change S-mask, the issue will appear again in +16 uFrame, +32 uframe, +48 uframe...
Hi Biyong,
What did you mean? Did you mean max number was 128? Even so, in spite of our goal was at most 8, however some of transactions didn't started for now.
So we checked ChipIdea USB descriptions in Chapter 65 of i.MX6SDL reference manual one more time and have some questions as following.
Can you help us debugging? See Fig.1 and 2 attached.
(Q) Is it available to specify which transaction issued in certain microframe with using S-mask in the Queue Head?
If yes, in our case there were 7 devices and corresponding 7 endpoints which scheduled sending within one microframe by setting S-mask field in the Queue Head,
then it maybe caused bandwidth shortage although it depends on the data size.
(Q) In above situation, will overflow transactions lose?
Best Regards.
