I just finished converting a working bulk design to use an isochronous endpoint and I think I may be misunderstanding what CCyIsoPktInfo.Length is trying to tell me.  Here's what I am observing:

1)  I fill my data buffer with a magic pattern before reading into it (host side--IN transfer).
2)  I read data from the isochronous endpoint using beginDataXfer / WaitForXfer / FinishDataXfer.  The endpoint is configured for 3 1K transfers per microframe. 
3)  All of the calls return success.  The bus analyzer indicates that all of the data was transmitted.  I iterate over the CCyIsoPktInfo structures to see how much of my data came through as expected.  A cleaned up code snippet:

int packets;
CCyIsocEndPoint *ep = ... // this is my endpoint
CCyIsoPktInfo *pktInfos = ep->CreatePktInfos(l, packets);
memset(pktInfos, 0, sizeof(CCyIsoPktInfo) * packets);

ret = ep ->FinishDataXfer(buf, l, c->Overlapped(), c->m_ptr, pktInfos);
for(int i = 0; i < packets; i++)
{
    if(pktInfos[i].Status != 0)
        break;       
               
    len += pktInfos[i].Length;
}
delete [] pktInfos;

At this point, I expect "len" to contain the length of data successfully sent through up to the first dropped packet (if there are any).  However, if I iterate over the first "len" bytes of the buffer, I find "holes" in the buffer where the original magic pattern still exists.  The holes always begin and end on 1K boundaries. 

I expected to see the CCyIsoPktInfo status return nonzero any time data wasn't copied into my buffer.  Am I doing something obviously wrong with the SDK or should I look elsewhere in my code for the bug?

Thanks!

 Hi,

    The Streamer example exaple that comes as part of Cypress SUiteUSB would be helpful for you. You can find that at the location "C:\Cypress\Cypress Suite USB 3.4.4\CyAPI\examples\Streamer" after installing SuiteUSB (http://www.cypress.com/?rID=34870). 

Thanks

Prajith

Thanks for the response.  Forgive the delay, but I was double checking everything to make sure that he question I'm asking is sensible. 

I used the streamer sample as an example and have gone as far as to cut and paste it into my loop and modify it only minimally to make it work with my application.  Right now, what I'm seeing that's most alarming is a surprisingly high failure rate.  According to the CCyIsoPktInfo array, I'm losing more than 5% of my packets.

At the same time, the CATC protocol analyzer data looks perfectly clean--the host is making the correct number of IN requests and all of the data being requseted is on the bus.  I can decode the raw dump from the bus and detect no errors, but I can look at the same transfer up in userspace software and I'm losing enough data to bring my protocol to a halt.

CPU utilization is around 10%, and I've tried queueing anywhere from 4 to 1024 transfer requests.  I've also tried tweaking the transfer size (always in multiples of 8 * 3 * 1024) with only minimal changes to the packet loss rate.

I understand that some losses are to be expected, but this seems extremely high.

 Hi,

I would like to take a look at the source of your application. Can you attach your source code here?

Regards,

Gayathri

Thanks for the follow up.  It's commercial code, so what I have attached is the loop with everything but the USB read portion removed.

When I define "DUMP_RAW" and look at the resulting dumped buffer, the results are definitely different from what I get from the same stream when I dump the data from that endpoint off of the wire.  I have observed a few things that are of interest:

1)  When I preinitialize my buffer with BAD_MAGIC (a token not found in the data stream), I often see bursts of BAD_MAGIC in my buffer.  Because they're a multiple of 1024 in length, it looks to me like when a packet is dropped, the driver seeks forward by a packet width without copying things.

2)  If I am expecting the values 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, in my stream, I'll sometimes see 1, 2, 3, 4, then 1024 bytes of BAD_MAGIC, and then 5, 6, 7, 8, 9,10.  No data lost, just a packet-sized "jump".  My guess is that this is the result of the device returning a zero length packet and then starting the data sequence in the next microframe. 

3)  The observation in (2) is not always true.  I modified my parser to seek past any BAD_MAGIC bytes in hopes of getting coherent data out, but there is still a substantial amount of missing data.

4)  This loop was quite stable when the endpoint was a bulk endpoint.  My first attempt at isochronous logic was simply changing the firmware to an isochronous enpdoint.  This gave me clean data on the line, but my host site parser stopped working.  I've pared the code down to roughly the loop that I just posted as I debugged it.

I'm sure that this is just a matter of me not understanding what the return codes are trying to tell me, so your guidance is much appreciated.

 Hi,

I thought of testing your app as such at my end so as to see if I can replicate the issue here. It would be easier for anyone to debug if the issue can be replicated. Please create a case at http://www.cypress.com/ -> Support -> Technical Support, so that one of Cypress engineers can take a look at this.

Regards,

Gayathri