CY7C68013A (FX2LP) isochronous IN transfer problem

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable
        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.   
0 Likes
9 Replies
Anonymous
Not applicable
        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...   
0 Likes
Anonymous
Not applicable
        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.   
0 Likes
Anonymous
Not applicable
        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...   
0 Likes
Anonymous
Not applicable
        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?   
0 Likes
Anonymous
Not applicable
        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....   
0 Likes
Anonymous
Not applicable
        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.   
0 Likes
Anonymous
Not applicable
        nah.... the host has to send IN tokens for the device to respond with packets... SOF just marks the start of the (micro)frame...   
0 Likes
Anonymous
Not applicable
        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.   
0 Likes
Anonymous
Not applicable
        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....   
0 Likes