Cy7C68013 Streamer input transfer ISOC loses data

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

cross mob
FrZa_2625781
Level 4
Level 4
First solution authored 25 replies posted 10 replies posted

Hi,

I am using the Streamer example with the Cy7C68013 with the isochronous transfer (3*1024 bytes or 1*1024 bytes and 8 or 16 packages per xfer).

With every transfer there are some bytes lost, namely 102 bytes with 8 PPX and 166 bytes with 16 PPX. This makes 38 bytes loss plus 8 bytes per PPX.

I modified the data that is preloaded into the buffers by the Streamer example so that the data is just increasing with every transferred byte and I can see where the loss happens.

The loss always happens at the end of the transfer.

The rLen value that is returned by the

     if (EndPt->FinishDataXfer(buffers, rLen, &inOvLap, contexts, isoPktInfos))

is just the mentioned amount smaller than the len value used with the

     EndPt->BeginDataXfer(buffers, len, &inOvLap);

command.

I checked if maybe just the returned data length value is smaller but the data actually in the buffer, but that is not the case (last 102 or 166 buffer bytes are zero).

Can anyone give my any hint of a clue?

0 Likes
1 Solution

Hello Frank Zander,

I modified the Streamer example code as you have mentioned and tried it using the streamer application and captured the data using a protocol analyzer. I find the pattern FF FF FF occurring at the start of the 1024 byte packet on all the data transactions.

Modifications to the code apart from what you have mentioned:

1. The below lines were commented out.

//SYNCDELAY;

//EP2CFG = 0xE0;  // EP2 is DIR=IN, TYPE=BULK, SIZE=512, BUF=4x // original values

//SYNCDELAY;

Please let me know why you have reverted it back to BULK endpoint type.

2. I have modified the descriptor file to indicate the endpoint as an ISOC endpoint with the MaxPacketSize as 1024.

Kindly, let me know if you face this issue only on certain PC/OS or is it common across different platforms.

Best regards,

Srinath S

View solution in original post

0 Likes
6 Replies
SrinathS_16
Moderator
Moderator
Moderator
1000 replies posted 750 replies posted 500 replies posted

Hello Frank Zander,

- Please let know how the firmware is modified to preload data into the buffers.

- Also, have you modified the application to save data onto a file on the disk?

Best regards,

Srinath S

0 Likes

Data prepatation (look for // begin modification and // end of modification):

void TD_Init(void)             // Called once at startup

{

   int i,j;

   // set the CPU clock to 48MHz

   CPUCS = ((CPUCS & ~bmCLKSPD) | bmCLKSPD1) ;

   SYNCDELAY;

   // set the slave FIFO interface to 48MHz

   IFCONFIG |= 0x40;

   SYNCDELAY;

    // Default interface uses endpoint 2, zero the valid bit on all others

    // Just using endpoint 2, zero the valid bit on all others

    EP1OUTCFG = (EP1OUTCFG & 0x7F);

    SYNCDELAY;

    EP1INCFG = (EP1INCFG & 0x7F);

    SYNCDELAY;

    EP4CFG = (EP4CFG & 0x7F);

    SYNCDELAY;

    EP6CFG = (EP6CFG & 0x7F);

    SYNCDELAY;

    EP8CFG = (EP8CFG & 0x7F);

    SYNCDELAY;

// begin modification

//    EP2CFG = 0xE0;  // EP2 is DIR=IN, TYPE=BULK, SIZE=512, BUF=4x // does not fill enough memory for 1024 sized buffers

    EP2CFG = 0xD8;  // EP2 is DIR=IN, TYPE=ISOC, SIZE=1024, BUF=4x // change to ISOC temporarily

// end of modification

   // We want to get SOF interrupts

   USBIE |= bmSOF;

   mycount = 0;

   // Prepare data

   for (i=1;i<5;i++)

   {

      EP2FIFOBUF[0] = LSB(mycount);

      EP2FIFOBUF[1] = MSB(mycount);

      EP2FIFOBUF[2] = USBFRAMEL;

      EP2FIFOBUF[3] = USBFRAMEH;

      EP2FIFOBUF[4] = MICROFRAME;

// begin modification

      EP2FIFOBUF[5] = 255; // just three times FF for beginning counting on a clean 8 byte address

      EP2FIFOBUF[6] = 255; // just three times FF for beginning counting on a clean 8 byte address

      EP2FIFOBUF[7] = 255; // just three times FF for beginning counting on a clean 8 byte address

// end of modification

      for (j=8;j<1023;j++)

      {

// begin modification

         EP2FIFOBUF = LSB(j);// changed from number of buffer to number of actual address in buffer (MSB and LSB)

         j++;                   // extra j++ because address takes two bytes

         EP2FIFOBUF = MSB(j)+4*(i-1); // add the number of the buffer in order to have 4*1024 bytes counted

      }

      EP2BCH = 0x04; // was 02 but need 04 for 1024 bytes put in memory

// end of modification

      EP2BCL = 0x00;

   }

// begin modification

   SYNCDELAY; // additional sync delay for changing back cfg to original values (does not hurt even if unnecessary)

   EP2CFG = 0xE0;  // EP2 is DIR=IN, TYPE=BULK, SIZE=512, BUF=4x // original values

   SYNCDELAY; // additional sync delay for changing back cfg to original values (does not hurt even if unnecessary)

// end of modification

    Rwuen = TRUE;                 // Enable remote-wakeup

}

Yes I save data to disk, but even without this the problem exists. Here is the modified code:

if (EndPt->Attributes == 1) // ISOC Endpoint
{   
    if (EndPt->FinishDataXfer(buffers, rLen, &inOvLap, contexts, isoPktInfos))
    {           
// begin modification
        if (bShowData)//modified: insertion
            outfile.write(reinterpret_cast<const char *>(buffers),rLen);//modified: insertion
// end of modification

        CCyIsoPktInfo *pkts = isoPktInfos;
        for (int j=0; j< PPX; j++)
        {
            if (pkts.Status == 0)
            {
                BytesXferred += pkts.Length;

                if (bShowData)
// begin modification
                    //Display16Bytes(buffers);//modified: commented out
// end of modification

                Successes++;
            }
            else
                Failures++;

            pkts.Length = 0;    // Reset to zero for re-use.
        }
// begin modification
        Failures=rLen; //insertion for monitoring correct transfer length
// end of modification
    }
    else
        Failures++;
           
}

First I only copied rLen to Failures to have it displayed in the form. When rLen was no multiple of 8192 I tried to investigate by the file write.

Interestingly this does not happen wirh BULK transfers.

0 Likes

Helllo Frank Zander,

- The endpoint is ISOC endpoint with the buffer size = 1024. So, 1024 bytes of data can be committed to the host, instead of the 512 bytes that is committed.

EP2BCH = 0x02;

EP2BCL = 0x00;

- Please share the data that is logged onto the disk file/ copy the data from the streamer application.

Best regards,

Srinath S

0 Likes

Hi,

I added the extra J++ because I need two bytes to count the numbers. So yes, I only save 512 values to the memory, but this covers 1024 bytes. That is also the reason for the 1023 instead of 1024.

This is the content of the disk file from ISOC transfer with 3 packages per microframe and 1024 bytes size each (I only post the interesting part, namely the beginning of the new buffers and where it eventually differs from the expected values).

The first column (offset 00) must match the LSB of the address, except when the line contains the first 8 bytes of the buffer, where it shows the LSB of the internal buffer count of the 68013. If it differs also on other lines, this is an indication that some bytes must have been missed before (first seen at address 00005FA0).

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  1C 00 87 00 00 FF FF FF 08 00 0A 00 0C 00 0E 00 

00000010  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00 

00000020  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00 

00000030  30 00 32 00 34 00 36 00 38 00 3A 00 3C 00 3E 00 

00000040  40 00 42 00 44 00 46 00 48 00 4A 00 4C 00 4E 00 

00000050  50 00 52 00 54 00 56 00 58 00 5A 00 5C 00 5E 00 

00000060  60 00 62 00 64 00 66 00 68 00 6A 00 6C 00 6E 00 

00000070  70 00 72 00 74 00 76 00 78 00 7A 00 7C 00 7E 00 

00000080  80 00 82 00 84 00 86 00 88 00 8A 00 8C 00 8E 00 

00000090  90 00 92 00 94 00 96 00 98 00 9A 00 9C 00 9E 00 

000000A0  A0 00 A2 00 A4 00 A6 00 A8 00 AA 00 AC 00 AE 00 

000000B0  B0 00 B2 00 B4 00 B6 00 B8 00 BA 00 BC 00 BE 00 

000000C0  C0 00 C2 00 C4 00 C6 00 C8 00 CA 00 CC 00 CE 00 

000000D0  D0 00 D2 00 D4 00 D6 00 D8 00 DA 00 DC 00 DE 00 

000000E0  E0 00 E2 00 E4 00 E6 00 E8 00 EA 00 EC 00 EE 00 

000000F0  F0 00 F2 00 F4 00 F6 00 F8 00 FA 00 FC 00 FE 00 

00000100  00 01 02 01 04 01 06 01 08 01 0A 01 0C 01 0E 01 

00000110  10 01 12 01 14 01 16 01 18 01 1A 01 1C 01 1E 01

...

000003D0  D0 03 D2 03 D4 03 D6 03 D8 03 DA 03 DC 03 DE 03 

000003E0  E0 03 E2 03 E4 03 E6 03 E8 03 EA 03 EC 03 EE 03 

000003F0  F0 03 F2 03 F4 03 F6 03 F8 03 FA 03 FC 03 FE 03 

00000400  1D 00 87 00 00 FF FF FF 08 04 0A 04 0C 04 0E 04  // first eight bytes of the second buffer

00000410  10 04 12 04 14 04 16 04 18 04 1A 04 1C 04 1E 04 

00000420  20 04 22 04 24 04 26 04 28 04 2A 04 2C 04 2E 04  

...

000007D0  D0 07 D2 07 D4 07 D6 07 D8 07 DA 07 DC 07 DE 07 

000007E0  E0 07 E2 07 E4 07 E6 07 E8 07 EA 07 EC 07 EE 07 

000007F0  F0 07 F2 07 F4 07 F6 07 F8 07 FA 07 FC 07 FE 07 

00000800  1E 00 87 00 00 FF FF FF 08 08 0A 08 0C 08 0E 08  // first eight bytes of the third buffer

00000810  10 08 12 08 14 08 16 08 18 08 1A 08 1C 08 1E 08 

00000820  20 08 22 08 24 08 26 08 28 08 2A 08 2C 08 2E 08 

...

00000BD0  D0 0B D2 0B D4 0B D6 0B D8 0B DA 0B DC 0B DE 0B 

00000BE0  E0 0B E2 0B E4 0B E6 0B E8 0B EA 0B EC 0B EE 0B 

00000BF0  F0 0B F2 0B F4 0B F6 0B F8 0B FA 0B FC 0B FE 0B 

00000C00  1F 00 87 00 00 FF FF FF 08 0C 0A 0C 0C 0C 0E 0C  // first eight bytes of the fourth buffer

00000C10  10 0C 12 0C 14 0C 16 0C 18 0C 1A 0C 1C 0C 1E 0C

00000C20  20 0C 22 0C 24 0C 26 0C 28 0C 2A 0C 2C 0C 2E 0C  

...

00000FD0  D0 0F D2 0F D4 0F D6 0F D8 0F DA 0F DC 0F DE 0F 

00000FE0  E0 0F E2 0F E4 0F E6 0F E8 0F EA 0F EC 0F EE 0F 

00000FF0  F0 0F F2 0F F4 0F F6 0F F8 0F FA 0F FC 0F FE 0F 

00001000  20 00 9D 07 07 FF FF FF 08 00 0A 00 0C 00 0E 00  // first eight bytes of the fifth buffer

00001010  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00  // followed by the bytes of the first

00001020  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00  // buffer because of first buffer rollover

...

00005BD0  D0 0B D2 0B D4 0B D6 0B D8 0B DA 0B DC 0B DE 0B 

00005BE0  E0 0B E2 0B E4 0B E6 0B E8 0B EA 0B EC 0B EE 0B 

00005BF0  F0 0B F2 0B F4 0B F6 0B F8 0B FA 0B FC 0B FE 0B 

00005C00  33 00 9E 07 05 FF FF FF 08 0C 0A 0C 0C 0C 0E 0C  // first eight bytes of the 24rd buffer

00005C10  10 0C 12 0C 14 0C 16 0C 18 0C 1A 0C 1C 0C 1E 0C  // followed by the bytes of the third

00005C20  20 0C 22 0C 24 0C 26 0C 28 0C 2A 0C 2C 0C 2E 0C  // buffer because of the fifth buffer rollover

...

00005F60  60 0F 62 0F 64 0F 66 0F 68 0F 6A 0F 6C 0F 6E 0F 

00005F70  70 0F 72 0F 74 0F 76 0F 78 0F 7A 0F 7C 0F 7E 0F 

00005F80  80 0F 82 0F 84 0F 86 0F 88 0F 8A 0F 8C 0F 8E 0F 

00005F90  90 0F 92 0F 94 0F 96 0F 98 0F 34 00 9E 07 05 FF  // here the 25th buffer begins at byte 5F9A

00005FA0  FF FF 08 00 0A 00 0C 00 0E 00 10 00 12 00 14 00  // followed by the bytes of the first

00005FB0  16 00 18 00 1A 00 1C 00 1E 00 20 00 22 00 24 00  // buffer because of sixth buffer rollover

00005FC0  26 00 28 00 2A 00 2C 00 2E 00 30 00 32 00 34 00  // the 25th buffer is the beginning of the

00005FD0  36 00 38 00 3A 00 3C 00 3E 00 40 00 42 00 44 00  // second transfer because one xfer has

00005FE0  46 00 48 00 4A 00 4C 00 4E 00 50 00 52 00 54 00  // 8*3*1024 bytes

00005FF0  56 00 58 00 5A 00 5C 00 5E 00 60 00 62 00 64 00 

00006000  66 00 68 00 6A 00 6C 00 6E 00 70 00 72 00 74 00  // here the 25th buffer should begin

00006010  76 00 78 00 7A 00 7C 00 7E 00 80 00 82 00 84 00  // but it began 102 bytes ago

00006020  86 00 88 00 8A 00 8C 00 8E 00 90 00 92 00 94 00 

...

0000BF10  76 0F 78 0F 7A 0F 7C 0F 7E 0F 80 0F 82 0F 84 0F 

0000BF20  86 0F 88 0F 8A 0F 8C 0F 8E 0F 90 0F 92 0F 94 0F 

0000BF30  96 0F 98 0F 4C 00 9F 07 05 FF FF FF 08 00 0A 00  // here the 49th buffer begins at byte BF34

0000BF40  0C 00 0E 00 10 00 12 00 14 00 16 00 18 00 1A 00  // now 204 bytes to early

0000BF50  1C 00 1E 00 20 00 22 00 24 00 26 00 28 00 2A 00 

0000BF60  2C 00 2E 00 30 00 32 00 34 00 36 00 38 00 3A 00 

0000BF70  3C 00 3E 00 40 00 42 00 44 00 46 00 48 00 4A 00 

0000BF80  4C 00 4E 00 50 00 52 00 54 00 56 00 58 00 5A 00 

0000BF90  5C 00 5E 00 60 00 62 00 64 00 66 00 68 00 6A 00 

0000BFA0  6C 00 6E 00 70 00 72 00 74 00 76 00 78 00 7A 00 

0000BFB0  7C 00 7E 00 80 00 82 00 84 00 86 00 88 00 8A 00

0000BFC0  8C 00 8E 00 90 00 92 00 94 00 96 00 98 00 9A 00 

0000BFD0  9C 00 9E 00 A0 00 A2 00 A4 00 A6 00 A8 00 AA 00 

0000BFE0  AC 00 AE 00 B0 00 B2 00 B4 00 B6 00 B8 00 BA 00 

0000BFF0  BC 00 BE 00 C0 00 C2 00 C4 00 C6 00 C8 00 CA 00

0000C000  CC 00 CE 00 D0 00 D2 00 D4 00 D6 00 D8 00 DA 00  // here the 49th buffer should begin

0000C010  DC 00 DE 00 E0 00 E2 00 E4 00 E6 00 E8 00 EA 00 

0000C020  EC 00 EE 00 F0 00 F2 00 F4 00 F6 00 F8 00 FA 00 

This is the content of the disk file from BULK transfer with 1 package per microframe and 512 bytes size each (I only post the interesting part, namely the beginning of the new buffers and where it eventually differs from the expected values with ISOC transfer but NOT with BULK):

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  05 77 D4 03 05 FF FF FF 08 00 0A 00 0C 00 0E 00 

00000010  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00 

00000020  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00 

00000030  30 00 32 00 34 00 36 00 38 00 3A 00 3C 00 3E 00 

00000040  40 00 42 00 44 00 46 00 48 00 4A 00 4C 00 4E 00 

00000050  50 00 52 00 54 00 56 00 58 00 5A 00 5C 00 5E 00 

00000060  60 00 62 00 64 00 66 00 68 00 6A 00 6C 00 6E 00 

00000070  70 00 72 00 74 00 76 00 78 00 7A 00 7C 00 7E 00 

00000080  80 00 82 00 84 00 86 00 88 00 8A 00 8C 00 8E 00 

00000090  90 00 92 00 94 00 96 00 98 00 9A 00 9C 00 9E 00 

000000A0  A0 00 A2 00 A4 00 A6 00 A8 00 AA 00 AC 00 AE 00 

000000B0  B0 00 B2 00 B4 00 B6 00 B8 00 BA 00 BC 00 BE 00 

000000C0  C0 00 C2 00 C4 00 C6 00 C8 00 CA 00 CC 00 CE 00 

000000D0  D0 00 D2 00 D4 00 D6 00 D8 00 DA 00 DC 00 DE 00 

000000E0  E0 00 E2 00 E4 00 E6 00 E8 00 EA 00 EC 00 EE 00 

000000F0  F0 00 F2 00 F4 00 F6 00 F8 00 FA 00 FC 00 FE 00

00000100  00 01 02 01 04 01 06 01 08 01 0A 01 0C 01 0E 01 

00000110  10 01 12 01 14 01 16 01 18 01 1A 01 1C 01 1E 01 

...

000001D0  D0 01 D2 01 D4 01 D6 01 D8 01 DA 01 DC 01 DE 01 

000001E0  E0 01 E2 01 E4 01 E6 01 E8 01 EA 01 EC 01 EE 01 

000001F0  F0 01 F2 01 F4 01 F6 01 F8 01 FA 01 FC 01 FE 01 

00000200  06 77 D4 03 05 02 06 02 08 02 0A 02 0C 02 0E 02  // first eight bytes of the second buffer

00000210  10 02 12 02 14 02 16 02 18 02 1A 02 1C 02 1E 02 

00000220  20 02 22 02 24 02 26 02 28 02 2A 02 2C 02 2E 02 

...

000003D0  D0 03 D2 03 D4 03 D6 03 D8 03 DA 03 DC 03 DE 03 

000003E0  E0 03 E2 03 E4 03 E6 03 E8 03 EA 03 EC 03 EE 03 

000003F0  F0 03 F2 03 F4 03 F6 03 F8 03 FA 03 FC 03 FE 03 

00000400  07 77 D4 03 05 FF FF FF 08 04 0A 04 0C 04 0E 04  // first eight bytes of the third buffer

00000410  10 04 12 04 14 04 16 04 18 04 1A 04 1C 04 1E 04 

00000420  20 04 22 04 24 04 26 04 28 04 2A 04 2C 04 2E 04  

...

000007D0  D0 07 D2 07 D4 07 D6 07 D8 07 DA 07 DC 07 DE 07 

000007E0  E0 07 E2 07 E4 07 E6 07 E8 07 EA 07 EC 07 EE 07 

000007F0  F0 07 F2 07 F4 07 F6 07 F8 07 FA 07 FC 07 FE 07 

00000800  09 77 F7 05 05 FF FF FF 08 00 0A 00 0C 00 0E 00  // first eight bytes of the fifth buffer

00000810  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00  // followed by the bytes of the first

00000820  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00  // buffer because of first buffer rollover

...

00000FD0  D0 07 D2 07 D4 07 D6 07 D8 07 DA 07 DC 07 DE 07 

00000FE0  E0 07 E2 07 E4 07 E6 07 E8 07 EA 07 EC 07 EE 07 

00000FF0  F0 07 F2 07 F4 07 F6 07 F8 07 FA 07 FC 07 FE 07 

00001000  0D 77 F7 05 06 FF FF FF 08 00 0A 00 0C 00 0E 00  // first eight bytes of the ninth buffer

00001010  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00  // this is the beginning of the second

00001020  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00  // transfer because bulk sends only one

00001030  30 00 32 00 34 00 36 00 38 00 3A 00 3C 00 3E 00  // pckg per microframe

...

00002FD0  D0 07 D2 07 D4 07 D6 07 D8 07 DA 07 DC 07 DE 07 

00002FE0  E0 07 E2 07 E4 07 E6 07 E8 07 EA 07 EC 07 EE 07

00002FF0  F0 07 F2 07 F4 07 F6 07 F8 07 FA 07 FC 07 FE 07 

00003000  1D 77 F8 05 00 FF FF FF 08 00 0A 00 0C 00 0E 00  // first eight bytes of the 25nd buffer

00003010  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00  // still everything ok

00003020  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00 

...

00005FD0  D0 07 D2 07 D4 07 D6 07 D8 07 DA 07 DC 07 DE 07 

00005FE0  E0 07 E2 07 E4 07 E6 07 E8 07 EA 07 EC 07 EE 07 

00005FF0  F0 07 F2 07 F4 07 F6 07 F8 07 FA 07 FC 07 FE 07 

00006000  35 77 F8 05 02 FF FF FF 08 00 0A 00 0C 00 0E 00  // first eight bytes of the 49th buffer

00006010  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00  // still everything ok

00006020  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00 

This is the content of the disk file from ISOC transfer with 1 package per microframe and 512 bytes size each (I only post the interesting part, namely the beginning of the new buffers and where it eventually differs from the expected values):

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  A1 18 A5 03 05 FF FF FF 08 00 0A 00 0C 00 0E 00 

00000010  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00 

00000020  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00 

00000030  30 00 32 00 34 00 36 00 38 00 3A 00 3C 00 3E 00 

00000040  40 00 42 00 44 00 46 00 48 00 4A 00 4C 00 4E 00 

00000050  50 00 52 00 54 00 56 00 58 00 5A 00 5C 00 5E 00 

00000060  60 00 62 00 64 00 66 00 68 00 6A 00 6C 00 6E 00 

00000070  70 00 72 00 74 00 76 00 78 00 7A 00 7C 00 7E 00 

00000080  80 00 82 00 84 00 86 00 88 00 8A 00 8C 00 8E 00 

00000090  90 00 92 00 94 00 96 00 98 00 9A 00 9C 00 9E 00 

000000A0  A0 00 A2 00 A4 00 A6 00 A8 00 AA 00 AC 00 AE 00 

000000B0  B0 00 B2 00 B4 00 B6 00 B8 00 BA 00 BC 00 BE 00 

000000C0  C0 00 C2 00 C4 00 C6 00 C8 00 CA 00 CC 00 CE 00 

000000D0  D0 00 D2 00 D4 00 D6 00 D8 00 DA 00 DC 00 DE 00 

000000E0  E0 00 E2 00 E4 00 E6 00 E8 00 EA 00 EC 00 EE 00 

000000F0  F0 00 F2 00 F4 00 F6 00 F8 00 FA 00 FC 00 FE 00 

00000100  00 01 02 01 04 01 06 01 08 01 0A 01 0C 01 0E 01 

00000110  10 01 12 01 14 01 16 01 18 01 1A 01 1C 01 1E 01 

...

000001D0  D0 01 D2 01 D4 01 D6 01 D8 01 DA 01 DC 01 DE 01 

000001E0  E0 01 E2 01 E4 01 E6 01 E8 01 EA 01 EC 01 EE 01 

000001F0  F0 01 F2 01 F4 01 F6 01 F8 01 FA 01 FC 01 FE 01 

00000200  A2 18 A5 03 05 02 06 02 08 02 0A 02 0C 02 0E 02  // first eight bytes of the second buffer

00000210  10 02 12 02 14 02 16 02 18 02 1A 02 1C 02 1E 02 

00000220  20 02 22 02 24 02 26 02 28 02 2A 02 2C 02 2E 02 

...

000003D0  D0 03 D2 03 D4 03 D6 03 D8 03 DA 03 DC 03 DE 03 

000003E0  E0 03 E2 03 E4 03 E6 03 E8 03 EA 03 EC 03 EE 03 

000003F0  F0 03 F2 03 F4 03 F6 03 F8 03 FA 03 FC 03 FE 03 

00000400  A3 18 A5 03 05 FF FF FF 08 04 0A 04 0C 04 0E 04  // first eight bytes of the third buffer

00000410  10 04 12 04 14 04 16 04 18 04 1A 04 1C 04 1E 04 

00000420  20 04 22 04 24 04 26 04 28 04 2A 04 2C 04 2E 04 

...

000007D0  D0 07 D2 07 D4 07 D6 07 D8 07 DA 07 DC 07 DE 07 

000007E0  E0 07 E2 07 E4 07 E6 07 E8 07 EA 07 EC 07 EE 07 

000007F0  F0 07 F2 07 F4 07 F6 07 F8 07 FA 07 FC 07 FE 07 

00000800  A5 18 2E 06 07 FF FF FF 08 00 0A 00 0C 00 0E 00  // first eight bytes of the fifth buffer

00000810  10 00 12 00 14 00 16 00 18 00 1A 00 1C 00 1E 00  // followed by the bytes of the first

00000820  20 00 22 00 24 00 26 00 28 00 2A 00 2C 00 2E 00  // buffer because of first buffer rollover

...

00000F70  70 07 72 07 74 07 76 07 78 07 7A 07 7C 07 7E 07 

00000F80  80 07 82 07 84 07 86 07 88 07 8A 07 8C 07 8E 07 

00000F90  90 07 92 07 94 07 96 07 98 07 A9 18 2F 06 03 FF  // here the 9th buffer begins at byte 0F9A

00000FA0  FF FF 08 00 0A 00 0C 00 0E 00 10 00 12 00 14 00  // followed by the bytes of the first

00000FB0  16 00 18 00 1A 00 1C 00 1E 00 20 00 22 00 24 00  // buffer because of second buffer rollover

00000FC0  26 00 28 00 2A 00 2C 00 2E 00 30 00 32 00 34 00  // the 9th buffer is the beginning of the

00000FD0  36 00 38 00 3A 00 3C 00 3E 00 40 00 42 00 44 00  // second transfer because one xfer has

00000FE0  46 00 48 00 4A 00 4C 00 4E 00 50 00 52 00 54 00  // 8*1*512 bytes

00000FF0  56 00 58 00 5A 00 5C 00 5E 00 60 00 62 00 64 00 

00001000  66 00 68 00 6A 00 6C 00 6E 00 70 00 72 00 74 00  // here the 8th buffer should begin

00001010  76 00 78 00 7A 00 7C 00 7E 00 80 00 82 00 84 00  // but it began 102 bytes ago

00001020  86 00 88 00 8A 00 8C 00 8E 00 90 00 92 00 94 00 

You see, with BULK transfer everything is ok, but with ISOC there are 102 bytes missing at the end of each transfer, no matter if the transfer has 8 single packages of 512 bytes each like the BULK transfer or if it has 3 tripple packages of 1024 bytes each.

0 Likes

Hi,

I suspect an error in the driver, so I updated it with the newest version I found. This was from the FX3 SDK 1.4.3 and it is dated May 8th, 2018.

Unfortunately the problem still is the same.

I noticed that the Streamer.h has also been changed in that SDK version.

Below they are shown in red:

if (EndPt->Attributes == 1) // ISOC Endpoint
{   
    if (EndPt->FinishDataXfer(buffers, rLen, &inOvLap, contexts, isoPktInfos))
    {         

        CCyIsoPktInfo *pkts = isoPktInfos;
        for (int j=0; j< PPX; j++)
        {
            if ((pkts.Status == 0) && (pkts.Length<=EndPt->MaxPktSize))
            {
                BytesXferred += pkts.Length;

                if (bShowData)
                    Display16Bytes(buffers);

                Successes++;
            }
            else
                Failures++;

            pkts.Length = 0;    // Reset to zero for re-use.
            pkts.Status = 0;

        }
    }
    else
        Failures++;
           
}

I assume the changes don't remove the problem as I suspect it in the FinishDataXfer command, but I'll try and report in a blink.

Edit:

Ok, it didn't remove the problem. Still 102 bytes missing at the end of the transfer.

I wonder why the data is always missing at the end. That does not look like any glitch problem or Windows messing up by not allowing enough time for the USB driver or allowing processor time too late.

But wait. One frame has 8 microframes, right? With 1*512 bytes that's 4096 bytes per frame (0x1000). And with the 3*1024 bytes that's 24576 bytes per frame (0x6000).

So the data loss always happens at the end of a frame.

Is it possible that somehow the PC starts a new frame while the previous one is still underways?

Or is there some kind of transmission that "announces" that the next frame will begin soon and this corrupts the transfer of the data?

0 Likes

Hello Frank Zander,

I modified the Streamer example code as you have mentioned and tried it using the streamer application and captured the data using a protocol analyzer. I find the pattern FF FF FF occurring at the start of the 1024 byte packet on all the data transactions.

Modifications to the code apart from what you have mentioned:

1. The below lines were commented out.

//SYNCDELAY;

//EP2CFG = 0xE0;  // EP2 is DIR=IN, TYPE=BULK, SIZE=512, BUF=4x // original values

//SYNCDELAY;

Please let me know why you have reverted it back to BULK endpoint type.

2. I have modified the descriptor file to indicate the endpoint as an ISOC endpoint with the MaxPacketSize as 1024.

Kindly, let me know if you face this issue only on certain PC/OS or is it common across different platforms.

Best regards,

Srinath S

0 Likes