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.
Solved! Go to Solution.
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 torus,
first, the USB spec says up to 127 Devices could be connected to a single Host, but it not means we can transmit the message to all the devices at the same time, the 127 device is just description from the address.
in your case, it seems you need to transmit the 7 1024Byte in the same uFrame, we should consider this issue from the bandwidth, Usb spec defined the largest bandwidth that the ISO transfer can occupy. If bandwidth exceed, SW should avoid such use case.
For the user’s case, if need 7 packet during one micro-frame, which is exceed the bandwidth. Either SW move the 2 packet to the next micro-frame, or reject the up-layer request.
Best regards,
YeXian
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.
---
What's the uSDHC IP mentioned here? Ultra Secured Digital Host Controller? Basicially for SD/MMC/eMMC?
How about the usb controller in the title for your question?
From the diagram, we can see a hub chip between?
What is issue in you case? i.MX6S can not talk to the hub chip?
Dear Biyong,
Sorry for confusing you. Let me correct as following. Please ignore my previous one.
(wrong) uSDHC
(correct) USB
I guess USB IP didn't support to reschedule exceed packets sending, so SW should treat of them.
Let me clarify several things.
- Does USB IP surprisingly support above feature?
- If yes, how to configure it?
- If not, USB 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?
In the field, some customers has use the hub like you here. not not sure it is 8 port.
for the hardware, the host port or a otg port is just connect to a hub.
for software linux, it will see the hub. and the linux doesn't know the low layer, which chip is running on,
if you have a sabresd reference board, you can connect a 8 port hub to the otg port to try.
Some time, we connect the hub to the reference board and connect lots devices such as mouse, keyboard, usb disks at the same time.
How many devices can connect to i.MX6? it mostly dependes on the hub chip and the power supply for the hub chip.
Dear Biyong
Please ignore hub chip or power because 7 devices can communicate if data size were 256 or 512.
Additionally saying, not hub but host leads 1st transactions using IN packet, I believe.
BR
USB core in i.MX6 is compliance requirements in 2.0.
Any ideas?
Have anybody ever been tried?
I hope that someone helps me.
Tao Zheng Nov 5, 2015 8:35 PM (in response to Carlos Jose Maria Casillas Mora)
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 All,
@Tony Zheng
I need to know how many devices can be used with iMAX6Q one HS host with integrated High Speed PHY USB(USB2.0) ? If I'm using USB hub.
Can I connect 14 devices to usb hub via this host port of iMAX6 ?
How it affect to the data speed and how can we understand limitations of iMAX6 USB2.0 ?
Regards,
Peter.
Hi Biyong,
this is a software issue, can you take this case.
Best regards,
YeXian
USB core in i.MX6 is compliance requirements in 2.0.
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.
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.
Best Regards.
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...