2 Replies Latest reply on Jun 6, 2017 11:50 PM by nisa

    No stream from dev->PC

    mirza.pasovic

      Hello 

         

      i am designing a device that will transfer data over FX3. I have implemented a slavefifo with 2 bit address, 32 bit data and 4 flags. FLAGA is a RDY dedicated flag for address 00 and FLAGB is watermark flag for address 00. FLAGC is a RDY dedicated flag for address 11 and FLAGD is watermark flag for address 11. 

         

      My slavefifo FX3 firmware is designed with AUTO commit On endpoint 00 i transfer data P-to-U and on endpoint 11 i transfred data U-to-P. 

         

      My problem is that i can transfer data from my host to device (U-to-P). In this case i see that flagc and flagd are responding completely correct. However when i send data from device to host my applications times out. Further more i see that in this case flagA and flagB are constantly high. I tried sending a short packet by asserting pktend and even in this case flagA and flagb are kept high. 

         

      Please can you tell me why i have this behavior? 

         

      I have attached my GIPF interface and source code.

         

      thank you

        • 1. Re: No stream from dev->PC
          mirza.pasovic

          Did anyone had a chance to take a look at what i am doing wrong?

          • 2. Re: No stream from dev->PC
            nisa

            I understand from your description that your implementation is very much similar to AN65974 firmware. Please test with the default AN65974 firmware before you make any changes. This firmware is tested. Once you make this work, i suggest you make changes one by one to see what is happening. 

               

            You mentioned that you are able to transfer U-to-P, but not P-to-U. Can you check if the state machines goes into this (In_data) state? (using CyU3PGpifGetSMState API).

               

            Please use a manual DMA channel to first check if you are getting a Prod event in the associated DMA. If you do not get a prod event, then something is wrong at the GPIF interface and the master may not be asserting the control signals properly. Please check this and confirm your observation.