T-SeriesのトピックRe: Scheduling problem with T1040's USB host controller

Scheduling problem with T1040's USB host controller

christophebeaus — Mon, 04 Apr 2016 07:16:19 GMT

Hi,

I'm using T1040’s USB host controller to access a Full Speed (USB 1.1) device.

Here is (very) basically how our periodic transfer descriptors are built:

TD EP# EP Type MaxLen S-mask C-mask

siTD1 EP3 ISO OUT 184 0x01 0x04

siTD2 EP2 ISO OUT 112 0x02 0x08

siTD3 EP6 ISO IN 16 0x04 0x10

qhTD4 EP7 INT OUT 64 0x04 0x10

qhTD5 EP8 INT IN 64 0x04 0x30

qhTD6 EP4 INT IN 8 0x08 0x20

stTD7 EP5 ISO IN 392 0x10 0xC0

and how they are chained together :

siTD1->next_link_ptr = siTD2 | UEH_CT_TYPE_siTD;

siTD2->next_link_ptr = siTD3 | UEH_CT_TYPE_siTD;

siTD3->next_link_ptr = qhTD4 | UEH_CT_TYPE_qhTD;

qhTD4->horiz_link_ptr = qhTD5 | UEH_CT_TYPE_qhTD;

qhTD5->horiz_link_ptr = qhTD6 | UEH_CT_TYPE_qhTD;

qhTD6->horiz_link_ptr = siTD7 | UEH_CT_TYPE_siTD;

The USB device is a custom card for which I expect 7 transactions in one frame (see pic1.jpg in attachment. Time slots 0/1000/2000 are where we observe the SOF)

But what I observe if different (see pic2.jpg in attachment). It appears that:

S-mask and C-mask are not respected (same result is obtained with all S-mask=0x01 and all C-mask=0x04)
EP6 and EP5 (both isochronous input data) are delayed in next frame

What does explain this behavior?

Can we force USB host controller to respect the specified scheduling?

If it could help, pic3.jpg is an overview of how we configured USB HC (without connected device here).

I'll be very grateful for any help !

Thanks

Re: Scheduling problem with T1040's USB host controller

Pavel — Fri, 08 Apr 2016 04:11:50 GMT

Your pictures show that the T1040 USB controller does not have possibilites for sending three start-split transactions and one complete-split transaction at microframe 2.

Change S-mask for EP6 and EP5 to 0x20 or 0x40.

Change also C-mask for these endpoints.

Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Scheduling problem with T1040's USB host controller

christophebeaus — Fri, 15 Apr 2016 14:34:14 GMT

Hi Pavel,

Thanks a lot for your interest!

I've just tried what you suggested. So here is my new configuration:

TD EP# EP Type MaxLen S-mask C-mask

siTD1 EP3 ISO OUT 184 0x01 0x00

siTD2 EP2 ISO OUT 112 0x02 0x00

siTD3 EP6 ISO IN 16 0x04 0x10

qhTD4 EP7 INT OUT 64 0x04 0x10

qhTD5 EP8 INT IN 64 0x08 0x20

qhTD6 EP4 INT IN 8 0x08 0x20

stTD7 EP5 ISO IN 392 0x10 0xC0

Unfortunately, as explained above, changing S-mask and C-mask has absolutely no impact. I obtain exactly the same result!

I've also tried to change the way my TDs are chained.

With:

EP5 -> EP6 -> EP3 -> EP2 -> EP7 -> EP8 -> EP4

I obtain:

EP5 -> EP6 -> EP7 -> EP8 -> EP4 for the first frame

EP3 -> EP2 for the second frame

With:

EP3 -> EP6 -> EP5 -> EP2 -> EP7 -> EP8 -> EP4

I obtain:

EP3 -> EP6 -> EP5 -> EP7 -> EP8 -> EP4 for the first frame

EP2 for the second frame

I guess that:

- because I use the USB HC's internal Transactions Translator (TT), the HC does not care about S-mask and C-mask (it directly deals with full speed and it doesn't need to send split packets)

- the USB HC decides by itself to postpone some transactions. I guess that it manages priority thus it only accepts ISO transactions that are set first, up to a maximum size or number (or another resource), then it deals with INT transactions.

May I be wrong?

How to learn about these limitations?

How to change or control this behavior?

Best regards

Christophe

Re: Scheduling problem with T1040's USB host controller

christophebeaus — Fri, 15 Apr 2016 15:16:46 GMT

Here is also in attachment the USB HC registers view once my device is connected.

Re: Scheduling problem with T1040's USB host controller

christophebeaus — Mon, 18 Apr 2016 12:54:15 GMT

Also, just to demonstrate that S-mask is unused, look at pic2. EP7's S-mask = 0x04, so EP7 transaction should not start before the third micro-frame. Yet we can see at pic2 that EP7 transaction starts during the second micro-frame!