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:
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
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!
-----------------------------------------------------------------------------------------------------------------------
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!
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