Missing data in short isochronous frames over USB

[rick_weil]

I'm working on a bare metal system that transfers VPU-compressed video from 1 iMX6 processor to another over USB using #isochronous transfers.

Assume a compressed video frame of 123456 bytes is to be sent over USB. This data is broken into 21K pieces to be sent in 5 full USB frames (7 full micro frames of 3K bytes each), with the remainder being sent in a final 15936 byte frame (5 full micro frames and the remainder of 576 bytes).  This is typically what happens, and it works fine.  USB frames shown in [brackets].

Normally case: 5 * [21K] + [15936] = 5 * [7 * 3072] + [(5 * 3072) + 576] = 123456 bytes sent in 6 frames.

BUT sometimes I see a different behavior.  Sometimes the transmitter groups the micro frames differently.  The initial transfer is not aligned with the first micro frame of a full USB frame transfer.  For example, say only 3 micro frames are filled with data (in slots 4,5,6, with slots 0,1,2,3 being empty). This is followed by a sequence of 21K frames, and a final partial frame being sent.

Sometimes case: [3 * 3072] + 5*[21K] + [6720] = [3 * 3072] + 5*[7 * 3072] + [(2 * 3072) + 576] = 123456 bytes sent in 7 frames.

The receive callback gets the expected buffer pointer and length as confirmed by a USB bus analyzer.  BUT in the "sometimes" case, the first frame transmitted (in this case [3 *3072]) does not contain updated data.  

Why in this case is the data NOT captured from the bus into the buffer?

[weidong_sun]

Hi,

Isochronous data transmission allows data errors, and bulk data transmission ensures the correctness. The former guarantees the real-time data, while the latter guarantees the correctness.

Have a nice day!

BR,

weidong

[rick_weil]

Hi Weidong,

Yes I understand isochronous transfers are not guaranteed, but this is not the problem I'm having. The data actually arrives, but is not in the right place...it seems to be integer multiple of 3K offset depending on the first microframe within the frame that is utilized to transfer data.  So, still an issue for me.  I'm looking now to see if the host is able to configure the endpoint to send only aligned data.

Thanks,

Rick

[weidong_sun]

Hello Rick,

    Below is answer from i.MX Expert team !

-------------------

If I understand correctly, you use high-bandwidth ISO endpoints to transfer compressed video data.

The transactions are organized as 3 x 1024 bytes per micro-frame, using 7 micro-frame slots (0-6) per frame for the first 5  frames and 1 frame with 5 micro-frame slots (0-4) plus 1 micro frame with only 576 bytes.

In the error case, it seems that we get the same sequence of micro frames, but they are shifted relative form the Frame start and the transactions in the first 3 micro-frames contain incorrect (old) data.

Just to make sure I understand correctly, did you check this in the protocol analyzer log? i.e, did you check the frame numbers in in the SOF packet and did the first transaction start after the 4th SOF following the one with the new frame number?

If that is the case, is there any chance that the transactions have been incorrectly scheduled? I'm asking this because the controller uses the frame index (same as SOF) to select the iTD from the periodic list and the entry in the iTD to select what transaction will be executed. If the index would be wrong for some reason, the frame number in the SOF would also be wrong. i.e there would be missing SOF packets.

If the index is correct, than the entries in the iTD would have to be incorrect to produce such output.

Regarding the old data,  the controller does not copy data. It reads it from memory (the buffers) into the internal FIFO and transmits the data. So when you see old data, it means it is reading from an old buffer/memory location. In this error case, it could mean that the active flag was set on an old transaction descriptor.

I would suggest to check if the descriptors are are always in the correct slot. Check the scheduling algorithm to ensure that it is always starting at a frame boundary and that the transaction is scheduled entirely before the controller starts using the iTD.

If more help is needed, please provide a binary copy of the protocol analyzer log and a description of the scheduling procedure.

-------------------------

Have a nice day!

BR,

Weidong