USB Data Transfer is Unreliable/Flaky using FX2LP Bulk Mode based on AN61345.

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

cross mob
Anonymous
Not applicable

USB Data Transfer Problem using FX2LP & AN61345.

The problem is that the USB data transfer between the Cypress chip and the PC is flaky and has really never worked 100%.
_______________________________

Here is my setup:

AN61345
FX2LP™-FPGA Interface
Associated Part Family: CY7C68013A

cyusb.sys 3.4.4.0
cyusb .net api 3.4.7.0

The USB-side of the chip is set up as EP6 Bulk In.  The device-side of the chip is set up as a Sync Slave Input FIFO with auto-commit, and FLAGA = EP6FF, externally supplied interface clock. The slave FIFO is being driven by an FPGA.

__________________________

Here is the .NET test code


            MyDevice.BulkInEndPt.TimeOut = 10000;
            MyDevice.BulkInEndPt.XferSize = 0x10000;

            byte[] buf = new byte[MyDevice.BulkInEndPt.XferSize / 4];


            while (true)
            {
                int nSize = buf.Length;
                bool bTimeout = !MyDevice.BulkInEndPt.XferData(ref buf, ref nSize, false);

                nTotalBytes += nSize;

                if (bTimeout)
                {
                    MyDevice.BulkInEndPt.Reset();
                    Console.WriteLine("Timeout Error");
                }
            }


_____________________

I have tried to send varying amounts of data from the FPGA, from 512B to 10MB. In this code, it never makes it through more than one successful iteration of XferData. XferData either:

1. Just times out on the first iteration.
2. Completes a couple "Zero-length" transfers and then times out.
3. Pulls in a first chunk of data, and then on the next iteration times out.

It seems to work best when the USB HighSpeedConfigDescriptor MaxPacketSize is 64 (instead of 512). But still it does one of the 3 things above.

I can see the signals on the FPGA. It always looks like the FPGA is sending out the same or more data than the PC receives. And so it looks like the problem occurs between the

.NET app and the Cypress chip.



I have tried to vary different parameters incluing:

* Cypress Firmware: USB HighSpeedConfigDescriptor - Max Packet Size: 64, 256, 512.
* Cypress Firmware: Auto Commit Size: 64, 512
* .NET Program: MyDevice.BulkInEndPt.XferSize: 512 - 65536
* .NET Program: MyDevice.BulkInEndPt.XferData buffer size



Here are the important parts of the firmware:

slave.c

void TD_Init( void )
{ // Called once at startup

  CPUCS = 0x12; // CLKSPD[1:0]=10, for 48MHz operation, output CLKOUT

 
    PINFLAGSAB = 0x8E; // FLAGA = EP6FF
    SYNCDELAY;
    PINFLAGSCD = 0x00;
    SYNCDELAY;
  PORTACFG = 0x00;       

  IFCONFIG =0x43; // external clk, 48 mhz (n/a), disable clk output, normal polarity, sync fifo, no debug, slave fifo

 
 

  // Only EP6 is used
                   
  EP2CFG = 0x02;                //clear valid bit
  SYNCDELAY;                   
  EP4CFG = 0x02;                //clear valid bit
  SYNCDELAY;
  EP6CFG = 0xE0;                // in 512 bytes, 4x, bulk
  SYNCDELAY;                                  
  EP8CFG = 0x02;                //clear valid bit
  SYNCDELAY;  

  SYNCDELAY;
  FIFORESET = 0x80;             // activate NAK-ALL to avoid race conditions
  SYNCDELAY;                    // see TRM section 15.14
  FIFORESET = 0x02;             // reset, FIFO 2
  SYNCDELAY;                    //
  FIFORESET = 0x04;             // reset, FIFO 4
  SYNCDELAY;                    //
  FIFORESET = 0x06;             // reset, FIFO 6
  SYNCDELAY;                    //
  FIFORESET = 0x08;             // reset, FIFO 8
  SYNCDELAY;                    //
  FIFORESET = 0x00;             // deactivate NAK-ALL


  // handle the case where we were already in AUTO mode...
  // ...for example: back to back firmware downloads...
  SYNCDELAY;                   
  EP6FIFOCFG = 0x00;           
 
  SYNCDELAY;
  EP6FIFOCFG = 0x0D;            // AUTOIN=1, ZEROLENIN=1, WORDWIDE=1
  SYNCDELAY;

 
    FIFOPINPOLAR = 0x00; // set all slave FIFO interface pins as active low
    SYNCDELAY;
}



BOOL DR_SetConfiguration( void )  
{ // Called when a Set Configuration command is received
 
  if( EZUSB_HIGHSPEED( ) )
  { // ...FX2 in high speed mode
   
    /*
    SYNCDELAY;
     EP6AUTOINLENH = 0x00;   // set core AUTO commit len = 64 bytes     
    SYNCDELAY;
    EP6AUTOINLENL = 0x40;
    */
                 

    SYNCDELAY;
     EP6AUTOINLENH = 0x20;   // set core AUTO commit len = 512 bytes     
    SYNCDELAY;
    EP6AUTOINLENL = 0x00;
   
  }
  else
  {
  // ...FX2 in full speed mode

    EP6AUTOINLENH = 0x00;        // set core AUTO commit len = 64 bytes
    SYNCDELAY;
    EP6AUTOINLENL = 0x40;
    SYNCDELAY;

  }
     
  Configuration = SETUPDAT[ 2 ];
  return( TRUE );        // Handled by user code
}



 

0 Likes
2 Replies
Anonymous
Not applicable

Please send a pattern from the FPGA.

   

Say 1,2,3,4.... and check the data being received on the host application. This will show whether the FX2LP is actually receiving data or if there are issues in the FPGA - FX2LP interface.

   

Use control center for this testing the data transfer. This should isolate the issue and expose possible root causes.

   

Regards,

   

Anand

0 Likes
Anonymous
Not applicable

I figured out the problem. The problem is in my code. If you look at the code you will see:

    SYNCDELAY;
     EP6AUTOINLENH = 0x20;   // set core AUTO commit len = 512 bytes     
    SYNCDELAY;
    EP6AUTOINLENL = 0x00;

   

 

   

It should be:

    SYNCDELAY;
     EP6AUTOINLENH = 0x02;   // set core AUTO commit len = 512 bytes     
    SYNCDELAY;
    EP6AUTOINLENL = 0x00;

   

 

   

Thanks for the help.

0 Likes