2 Replies Latest reply on Dec 4, 2016 6:49 PM by userc_39339

    DMA problem with "COMMIT" funtion of GPIF II

    userc_39339

      I am working with a FX3 firmware for communication board
      which has a FX3 connected to a FPGA via GPIF II, and I have some trouble.

         

      In this system, FX3 relays data from FPGA to USB with DMA. 
      Configurations are as following:
      1) GPIF II is configured as Slave FIFO mode.
      2) DMA type is CY_U3P_DMA_TYPE_AUTO
      3) FPGA asserts "EOD" signal when FPGA stops producing data.
      GPIF II is configured to "COMMIT" buffer when GPIF II receives "EOD" signal.
      4) The number of DMA buffers is 8.
      5) FPGA waits to transfer data while "DMA_Ready" signal is not asserted.

         

      My probrem is as following:
      1) DMA channel doesn't work after receiving "EOD" signal.
      2) PC side only receives data until first "EOD" signal is asserted.
      3) CyU3PDmaChannelGetBuffer returns code 0x47 (71) CY_U3P_ERROR_INVALID_SEQUENCE.
      4) It seems that DMA transfers from FPGA to DMA buffer are done 8 times - that is number of buffers -  using "EOD" signal 8 times.
       
      Is there any setting I have to configure before using "COMMIT" function of GPIF II,
      or any procedures FX3 firmware have to do after a buffer is committed?

         

      Any hints are appreceiated. 

         


      ------------------------------------------
      *This is my code to configure DMA channel:

         

      static void ReceiveDataStream_DMA_Initialize( uint16_t size ){
          CyU3PDmaChannelConfig_t dmaCfg;
          CyU3PReturnStatus_t apiRetStatus = CY_U3P_SUCCESS;

         

          const int WATERMARK_OFFSET = 4;        
          
          //Create GPIF II to USB channel
          dmaCfg.size = size * 8;                //size is 1024 with USB 3.0
          dmaCfg.count = 8;
          dmaCfg.prodSckId = GPIF2_RX_STREAM_PRODUCER_SOCKET;
          dmaCfg.consSckId = EP_RX_STREAM_CONSUMER_SOCKET;
          dmaCfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
          dmaCfg.notification = 0;
          dmaCfg.cb = NULL;
          dmaCfg.prodHeader = 0;
          dmaCfg.prodFooter = 0;
          dmaCfg.consHeader = 0;
          dmaCfg.prodAvailCount = 0;

         


           apiRetStatus = CyU3PDmaChannelCreate (&glReceiveDataStream_DMA_Handle,
                   CY_U3P_DMA_TYPE_AUTO, &dmaCfg);
           if (apiRetStatus != CY_U3P_SUCCESS)
           {
               ErrorHandler(apiRetStatus);
           }

         

           apiRetStatus = CyU3PGpifSocketConfigure(
                   GPIF2_RX_STREAM_THREAD,        
                   GPIF2_RX_STREAM_PRODUCER_SOCKET,
                   dmaCfg.size - WATERMARK_OFFSET,
                   CyTrue,                        
                   2                                
                   );
           if (apiRetStatus != CY_U3P_SUCCESS)
           {
               ErrorHandler(apiRetStatus);
           }

         


           apiRetStatus = CyU3PDmaChannelSetXfer (&glReceiveDataStream_DMA_Handle, 0);
           if (apiRetStatus != CY_U3P_SUCCESS)
           {
               ErrorHandler(apiRetStatus);
           }
           return;
      }

        • 1. Re: DMA problem with "COMMIT" funtion of GPIF II
          kexu_1593951

          I have a similar question. My experiment the PC only receives 1 IN transaction on a DMA channel. I followed the reference design to COMMIT a dma buffer. 

             

          Are there any more steps after COMMIT? 

          • 2. Re: DMA problem with "COMMIT" funtion of GPIF II
            userc_39339

            I found that the reason of following one was obvious - since 8 buffers were already committed by EOD (PKTEND) signal from FPGA. 

               

            >3) CyU3PDmaChannelGetBuffer returns code 0x47 (71) CY_U3P_ERROR_INVALID_SEQUENCE.

               

            I tried an another method that don't use EOD (PKTEND) signal for flow control.
            This worked well and data stream continuously flowed  to PC side.

            However, buffers have to be filled before transfer in the another method.
            My system requires flow control so I sitll want to solve this problem.