Anonymous
Not applicable
Aug 04, 2009
04:59 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 04, 2009
04:59 PM
We have a device that uses a CY7C68013A chip to transfer video data. It is configured to perform isochronous transfers at 3x 1024 bytes per microframe, using endpoint 2 with quad-buffered 1024 byte FIFOs. Streaming video can have a varying data rate, though, so not every transfer is filled up. It is said that the FX2LP can automatically send zero-length packets when necessary, but in practice transfers shorter than 2048 bytes are improperly transmitted, causing the transaction error bit to be set by the host USB controller. This happens whether we use externally generated data fed into the FIFOs or manually generate data and commit packets with the firmware. Is there anything special one has to do to commit short transfers? Do we have to set anything to enable automatic zero-length packets? Thanks.
9 Replies
Anonymous
Not applicable
Aug 05, 2009
12:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 05, 2009
12:31 AM
I don't think there is anything to be set to do that. What do you mean by transaction error bit is set... i mean does it mean turn-around time error or corrupted packet... In either case do you try using a CATC trace to analyze what is actually going on in the bus...
Anonymous
Not applicable
Aug 05, 2009
10:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 05, 2009
10:07 AM
As far as I can tell, the EHCI controller sets bit 28 in the relevant isochronous transfer descriptor (XactErr). From the EHCI specification, section 3.3.2:
"Set to a one by the Host Controller during status update in the case where the host did not receive a valid response from the device (Timeout, CRC, Bad PID, etc.). This bit may only be set for isochronous IN transactions."
I was under the impression that when the FX2LP receives a SOF, it looks for FIFOs that are committed and sends out however much it can, padding with zero-length packets as needed to avoid errors. Whatever it is doing, though, the host controller does not accept it.
For short transfers I send as many full packets of 1024 as possible and then a short packet, e.g. 1536 would be split into 1024 + 512. For some reason packets of exactly 2048 work (1024 + 1024), but any shorter does not. Perhaps the controller does not accept short packets followed by zero-length packets? This seems inconsistent with the specification and with common sense.
I have considered using a USB analyzer but they are rather pricey.
"Set to a one by the Host Controller during status update in the case where the host did not receive a valid response from the device (Timeout, CRC, Bad PID, etc.). This bit may only be set for isochronous IN transactions."
I was under the impression that when the FX2LP receives a SOF, it looks for FIFOs that are committed and sends out however much it can, padding with zero-length packets as needed to avoid errors. Whatever it is doing, though, the host controller does not accept it.
For short transfers I send as many full packets of 1024 as possible and then a short packet, e.g. 1536 would be split into 1024 + 512. For some reason packets of exactly 2048 work (1024 + 1024), but any shorter does not. Perhaps the controller does not accept short packets followed by zero-length packets? This seems inconsistent with the specification and with common sense.
I have considered using a USB analyzer but they are rather pricey.
Anonymous
Not applicable
Aug 06, 2009
06:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 06, 2009
06:09 AM
You have set FX2LP to respond with 3 iso packets per microframe. If the 2nd or 1st packet sent is a short packet then FX2LP will not be sending any packets for the rest of the microframe. I remember reading it in the TRM. Have you tried sending partial packets in the 3rd packet i.e packet size between 2048 and 3072 to see if this error occurs...
Anonymous
Not applicable
Aug 06, 2009
04:37 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 06, 2009
04:37 PM
Sending packets with total length between 2048 and 3072 does work. However, if I want to send a packet shorter than that (1024, for example), what am I supposed to do?
Anonymous
Not applicable
Aug 06, 2009
11:09 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 06, 2009
11:09 PM
I've not read the host spec and am not sure if the host is supposed to ask for 3 packets in a microframe when the first or second packet is a short packet... without the CATC trace we can't be sure whether the host is actually querying or setting error since the number of packets received is less... if possible i'll do some probing on my side and update you on what i observe....
Anonymous
Not applicable
Aug 07, 2009
11:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 07, 2009
11:07 AM
As far as I can tell the host just sends out a SOF packet every microframe, and the device responds (in the 3x case) with PIDs of DATA2, DATA1, and DATA0 in that order. I was under the impression that the FX2LP handles all of this data synchronization automatically, though.
Anonymous
Not applicable
Aug 07, 2009
11:57 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 07, 2009
11:57 AM
nah.... the host has to send IN tokens for the device to respond with packets... SOF just marks the start of the (micro)frame...
Anonymous
Not applicable
Aug 07, 2009
12:49 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 07, 2009
12:49 PM
Yes that is right, I forgot. Well, if you can find out what is going on it would be great, since I have been working on this for weeks and cannot figure it out.
Anonymous
Not applicable
Aug 16, 2009
05:17 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 16, 2009
05:17 PM
Dude i've been caught with some crazy stuff lately... will ping u with my probing as soon as i can... btw when it comes to high bandwidth like your case the device would be sending mdata PIDs....