3 Replies Latest reply on May 8, 2017 9:22 PM by rghe

    DMA callback transfer (image sensor project)

    btaylor_2212921

       I've got an image sensor connected to an FX3 device using the AN75779 application note.  I've modified the firmware to transfer RAW data instead of UVC.  I have an application to receive the data in RAW form.  My trouble is the DMA callback is only happening 9 times, and it's very consistent.  Never more or less. Should be about 23 times.  I'm confident my Image sensor is working correctly and setup correctly.  After the 9 callbacks it will never go back unless I restart the firmware again from the beginning.  Currently, I'm only trying to capture one frame, for testing and have a breakpoint in the GPIF interrupt callback (triggered by !FV in state machine) then check how many callbacks occurred by having a variable increment in the callback. Is there something I need to do to reset DMA?  Could it be that there is an error on the PC side and the FX3 is waiting for something from the PC the I'm missing?  

         

      As another note I'm using bulk transfer.

         

      Thanks a ton for any help that can be provided!

         

      Brandon

        • 1. Re: DMA callback transfer (image sensor project)
          nisa

          You can check if the FX3 is getting data from the sensor. In the DMA channel, you can have a UART print to check for PROD and CONS event to identify if the FX3 is getting the data and if the host is reading it from the FX3. This will give an idea, why the transfer is getting stuck after 3 buffers.

             

          Please refer the attached thread for RAW streaming using FX3: http://www.cypress.com/forum/usb-known-problems-and-solutions/fx3-cx3-firmware-streaming-raw-image-data-using-cypress

          • 2. Re: DMA callback transfer (image sensor project)
            btaylor_2212921

            Nishant/Support,

               

            I'm still having trouble with transfers from the Slave to the Host.  I'm getting random number of transfers with each frame and don't know why?  I get 4, 7, 11, 34, 50 etc. totally random.  I should be getting 22 @ 16384 bytes transfers and one partial 512 byte transfer. with each frame.  I've been watching the glDmaDone variable to see the number of times I get successful commits.  The number of commits in the variable for the Slave is the same as the number transfers the Host receives so I believe that the transfers are working.  I do get some error 71 sequence errors which hopefully is a clue.  I'm wondering if the problem is in the state machine?  Do you have a process that I could follow to help find the problem?  I unfortunately do not have a serial port on this board to use for trouble shooting.  This is a custom board.  I'll need to use variables for debug.

               

            I've also tried changing the code to Single channel DMA for testing just to see if the result was the same and it is.

               

            Another question about the clock input from the image sensor (GPIO16) does this have a divisor?  Does the state machine clock from the image sensor clock that is connected to GPIO16?  So if my image sensor is 24Mhz then the state machine is clocking at 24Mhz?  I'm wondering if there is a divisor that could be causing the problem?

               

            Any help you could provide would be greatly appreciated!

               

            Have a good weekend,

               

            Brandon

            • 3. Re: DMA callback transfer (image sensor project)
              rghe

              Brandon,

                 

               

                 

              If you are getting Invalid Sequence error (error code:71) , please refer to following Knowledge Base Article:

                 

              http://www.cypress.com/knowledge-base-article/invalid-sequence-error-multi-channel-commit-buffer-kba218830

                 

               

                 

              The GPIF II state machine clocks from the image sensor clock connected to PCLK (GPIO[16])