Our application is streaming video to the host via USB 2.0. The host has a Intel 82801I UHCI controller.

We have observed that when the video streaming endpoint is configured for high-bandwidth operation (multiple transaction opportunites per microframe), "runt" microframes with less than one packet of data never make it to the host. This leads to a black segment at the bottom right of each video frame.

I have traced the data flow in this case and as far as I can tell, the runt buffer is being committed to the USB socket properly. The DMA descriptors for that socket buffer are consistent with what I would expect, including the EOP flag.

Since this problem seems to be limited to cases where there is less than one packet of data committed, I am suspecting a hardware issue in the DATA PID sequencing required by USB 2.0 section 5.9.2.

Unfortunately I don't have access to a bus analyzer to see what is going over the wire. Has anyone encountered similar issues, or seen this case work in FX2 or FX3? Is it possible I'm doing something wrong in the firmware?

Hi,

Do you by any chance have a CATC analyzer to observe what is happening on the bus?

For isochronous endpoint since it doesn't have NRDY (or NAK when it comes to USB2.0) the concept of transaction is slightly different than other endpoints. If the host doesn't receive the specified amount of time it'll not have a way of knowing whether it is due to packet corruption of due to lack of response from device. So the host will time out the transaction. Please look at section 8.1 of the USB3.0 spec to understand this better.

Regards,

Anand

Anand -

I don't have access to a bus analyzer  :(

I don't think it is a transaction timeout. We lose data consistently at the end of each frame, which is the only place that runt packets occur.

I have been able to get the cyfxisosrcsink project to behave in a similar manner. Building the firmware with the attached patch file applied will cause the streamer application to report all received packets as bad. It appears that all the IRPs fail with USBD_STATUS_ISOCH_REQUEST_FAILED. 

If g_commitLength is changed to be >= HS_MAX_BYTES_PER_PACKET the data streams just fine. So it is definitely something specific to committing less than one packet of data to a USB socket configured for multiple packets per microframe.

Steve

Cypress has acknowledged that the FX3 sends the wrong PID in this case.
The workaround to transmit a "runt" isochronus packet over a high-bandwidth endpoint is as follows:

* Wait for all data already commited to the USB egress socket to drain
* Reconfigure the endpoint with isoPkts = 1
* Commit the runt packet to the USB egress socket
* Wait for the USB egress socket to drain
* Reconfigure the endpoint with the desired isoPkts value

Update...

This bug appears to have some nuances that were not obvious at first.

In general, the FX3 sends the wrong DATA PID for any isochronous IN transaction when there are less packets to send during a microframe than the endpoint is configured for. The bug includes transmission of ZLPs when the endpoint is configured for high-bandwidth mode.

The few exceptions to the buggy behavior seem to be:

1. If the endpoint is configured for 3 packets per microframe, and exactly 1 or exactly 2 packets are committed
2. If the endpoint is configured for 2 packets per microframe, and exactly 1 packet is committed
3. If the endpoint is configured for 1 packet per microframe, and no packets are committed (a ZLP case) 

On-the-fly reconfiguration can be used to fix ZLP transmission for high-bandwidth endpoints, but it is a pain to do, and success requires some knowledge of where to expect lulls in incoming data. Fortunately for my application, video data seems to be predictable enough that the band-aid works.

Steve

Sorry, to clarify:

I should have said the bug affects ZLP transmission. 
I did not mean to imply that the bug results in transmission of ZLPs in cases where none are expected.

Steve