- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Tags:
- data loss
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
j++; // extra j++ because address takes two bytes
EP2FIFOBUF
}
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
{
BytesXferred += pkts
if (bShowData)
// begin modification
//Display16Bytes(buffers);//modified: commented out
// end of modification
Successes++;
}
else
Failures++;
pkts
}
// 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
{
BytesXferred += pkts
if (bShowData)
Display16Bytes(buffers);
Successes++;
}
else
Failures++;
pkts
pkts
}
}
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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