How many USB devices can handle by i.MX6S USB host controller?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How many USB devices can handle by i.MX6S USB host controller?

Jump to solution
2,392 Views
torus1000
Contributor V

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.

7_usb_devices.gif

Tags (1)
0 Kudos
1 Solution
1,858 Views
tonyzheng
NXP Employee
NXP 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...

View solution in original post

0 Kudos
14 Replies
1,858 Views
b51415
NXP Employee
NXP Employee

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

0 Kudos
1,858 Views
torus1000
Contributor V

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.

---

update01.gifupdate02.gif

0 Kudos
1,858 Views
BiyongSUN
NXP Employee
NXP Employee

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?

0 Kudos
1,858 Views
torus1000
Contributor V

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?

0 Kudos
1,858 Views
BiyongSUN
NXP Employee
NXP Employee

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.

0 Kudos
1,858 Views
torus1000
Contributor V

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

0 Kudos
1,858 Views
BiyongSUN
NXP Employee
NXP Employee

USB core in i.MX6 is compliance requirements in 2.0.

0 Kudos
1,858 Views
torus1000
Contributor V

Could you/anyone answer my above last 2 questions in red?

Any ideas?

Have anybody ever been tried?

I hope that someone helps me.

0 Kudos
1,858 Views
karina_valencia
NXP Apps Support
NXP Apps Support

Tao ZhengEmployee

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...

0 Kudos
1,858 Views
peteramond
Contributor V

Hi All,

torus1000

@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.

0 Kudos
1,858 Views
b51415
NXP Employee
NXP Employee

Hi Biyong,

this is a software issue, can you take this case.

Best regards,

YeXian

0 Kudos
1,858 Views
BiyongSUN
NXP Employee
NXP Employee

USB core in i.MX6 is compliance requirements in 2.0.

0 Kudos
1,858 Views
torus1000
Contributor V

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.

Fig1.gifFig2.gif

0 Kudos
1,859 Views
tonyzheng
NXP Employee
NXP 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...

0 Kudos