6 Replies Latest reply on Oct 20, 2020 12:47 PM by NiCo_4789341

    CX3 non-UVC buffer size customization

    NiCo_4789341

      I've been adapting the code from FX3 / CX3 Firmware for Streaming RAW Image Data using Cypress Driver to my hardware.

      I can now use the Streamer application to receive data and the data-rate perfectly fits the theoretical H*V*bpp*fps.

       

      I've set the GPIF II bus width to 24 and I'm using multiple-to-one transfers with those (default) settings:

      #define CX3_UVC_DATA_BUF_SIZE               (0x6000)    // DMA Buffer Data Size Used: 24576 Bytes
      #define CX3_UVC_PROD_HEADER                 (0)        // UVC DMA Buffer Header Size
      #define CX3_UVC_PROD_FOOTER                 (0)         // UVC DMA Buffer Footer Size

       

      I wonder why those are the only settings I can make work!

      I'm trying to set the header and footer in order to add a custom payload (in principle this is not different from UVC 12-bytes header)

       

      I've made experiments with differets sets of values, in order to keep:

      1. CX3_UVC_DATA_BUF_SIZE + CX3_UVC_PROD_HEADER + CX3_UVC_PROD_FOOTER divisible by 16

      2. CX3_UVC_DATA_BUF_SIZE divisible by 16 and 24.

      3. CX3_UVC_DATA_BUF_SIZE * CX3_UVC_STREAM_BUF_COUNT * CX3_UVC_SOCKET_COUNT < ~220KB

       

      In fact I get no errors from the CyU3PMipicsiGpifLoad and CyU3PGpifSMStart nor from the CyU3PDmaMultiChannelCreate calls.

      Nevertheless, when I start the streamer it reads a few bytes at the very beginning, then the device enters in a loop of "stop and restart".

       

      Seems like if I setup the producer to write in the DMA buffer using offsets (header and/or footer) something goes wrong.

       

      Can someone help me? Am I missing some constaint?

        • 1. Re: CX3 non-UVC buffer size customization
          RashiV_61

          Hello,

           

          Please let me know the video resolution and frame rate that you are streaming through CX3.

          Also, add the debug prints to get the status of glDmaDone, glDMATxCount, glHitFV inside the for loop of CyCx3UvcAppThread_Entry function and share the UART debug prints

           

          - Please let me know if you get the CX3_DMA_RESET_EVENT event. This event is set at two instances in the firmware

          1) When CyU3PDmaMultiChannelCommitBuffer API int the CyCx3UvcAppDmaCallback fails. Please check the return status of this API.

          2) When the frame timer expires UvcAppProgressTimer

          If this event occurs when you change the DMA buffer setting, please let me know which of the above  two instances causes the CX3_DMA_RESET_EVENT

           

          Please let us know the CX3_UVC_DATA_BUF_SIZE, CX3_UVC_PROD_HEADER, CX3_UVC_PROD_FOOTER, and CX3_UVC_STREAM_BUF_COUNT after the modifications to the firmware.

           

          Regards

          Rashi

          • 2. Re: CX3 non-UVC buffer size customization
            NiCo_4789341

            Hi Rashi,

             

            my application is actually a stereo-camera. The MIPI lines from two sensors are "mixed" into one by an little FGA (crossfire by Lattice), hence the frame size is a little bit uncommon: 2784x1000@~60fps

             

            CyU3PMipicsiCfg_t RAW10_DUAL_1392x1000 =

            {

                    CY_U3P_CSI_DF_RGB888,

                    2,

                    2,

                    99,

                    CY_U3P_CSI_PLL_FRS_250_500M,

                    CY_U3P_CSI_PLL_CLK_DIV_4,

                    CY_U3P_CSI_PLL_CLK_DIV_4,

                    0x0000,                                                                                // uint16_t mClkCtl - set 0x1818 to get PLL_CLK/100 MCLK

                    CY_U3P_CSI_PLL_CLK_DIV_2,

                    2784,

                    50

            };

             

            Today I've been working on a different desktop machines and I've experienced a weird bahavior.

             

            So, I have two different machines, call them pc-A and pc-B.

            Both of them work flawlessly with the same firmware in UVC mode.

             

            When I change to "custom bulk mode" pc-A works OK with those settings:

            #define CX3_UVC_STREAM_BUF_COUNT            (4)
            #define CX3_UVC_DATA_BUF_SIZE               (0x6000)   // DMA Buffer Data Size Used: 24576 Bytes
            #define CX3_UVC_PROD_HEADER                 (0)        // UVC DMA Buffer Header Size
            #define CX3_UVC_PROD_FOOTER                 (0)        // UVC DMA Buffer Footer Size

            but pc-B cannot stream at all.

             

            If I try a slightly different settings, for example:

            #define CX3_UVC_STREAM_BUF_COUNT            (4)
            #define CX3_UVC_DATA_BUF_SIZE               (0x6000)   // DMA Buffer Data Size Used: 24576 Bytes
            #define CX3_UVC_PROD_HEADER                 (48)       // UVC DMA Buffer Header Size
            #define CX3_UVC_PROD_FOOTER                 (0)        // UVC DMA Buffer Footer Size

             

            neither pc-A nor pc-B can stream any more.

             

            In both cases this is the problem:

            CX3_DMA_RESET_EVENT is always triggered by an error in the CyU3PDmaMultiChannelCommitBuffer function.

             

            Here is the debug otput:

            AppInit: GpifSMStart passed

            bRType = 0xC0, bRequest = 0xA0, wValue = 0xE600, wIndex = 0x0, wLength= 0x1

            bRType = 0x40, bRequest = 0x99, wValue = 0x0, wIndex = 0x0, wLength= 0x0            <- start command

            Callback error: glDmaDone = 8 glDMATxCount = 21  glHitFV  = 0

            Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

            Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

            Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

            Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

            ..

            Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

            [... infinite sequence]

             

            thank you for your suggestions.

            • 3. Re: CX3 non-UVC buffer size customization
              YashwantK_46

              Hello NiCo_4789341,

               

              Can you please let me know if the device is enumerating properly in both the cases?


              Also, can you please share your firmware so that I can review it on my end?

               

              Regards,

              Yashwant

              • 4. Re: CX3 non-UVC buffer size customization
                NiCo_4789341

                Hi Yashwant,

                 

                I cannot see any problem with enumeration.

                I wonder if the problem could be more on the host application side, maybe related to different USB 3.0 chipsets.

                 

                Shall I post my code here in the blog?

                I'm developing this device for a customer, under NDA.

                • 5. Re: CX3 non-UVC buffer size customization
                  YashwantK_46

                  Hello NiCo_4789341,

                   

                  When I change to "custom bulk mode" pc-A works OK with those settings:

                  #define CX3_UVC_STREAM_BUF_COUNT           (4)
                  #define CX3_UVC_DATA_BUF_SIZE              (0x6000)  // DMA Buffer Data Size Used: 24576 Bytes
                  #define CX3_UVC_PROD_HEADER                (0)       // UVC DMA Buffer Header Size
                  #define CX3_UVC_PROD_FOOTER                (0)       // UVC DMA Buffer Footer Size

                  but pc-B cannot stream at all.

                   

                  => Can you please let me know the difference between both the PCs?
                  Are both the PC's using the windows or are they using different OS?

                  Let me know which host controllers are present in them as well.

                   

                  Also, in the firmware, please add this in the dma callback as shown in bold:

                   

                  status = CyU3PDmaMultiChannelCommitBuffer (chHandle, (DmaBuffer.count + CX3_UVC_PROD_HEADER), 0)

                              if (status != CY_U3P_SUCCESS)

                              {     

                                      CyU3PDebugPrint (4, "CommitBuffer Failure: %x", status);

                                      CyU3PEventSet(&glCx3Event, CX3_DMA_RESET_EVENT,CYU3P_EVENT_OR);

                                      break;                 

                              }

                   

                  This would help in understanding the error code and debug better.

                   

                  Also, you can comment the below line:

                  CyU3PDebugPrint(4,"\n\rCallback error: glDmaDone = %d glDMATxCount = %d  glHitFV  = %d", glDmaDone, glDMATxCount, glHitFV);

                   

                  After doing the above changes, share the UART traces in pc-B.

                   

                  Also, please provide Wireshark traces for both the PC's to get a better understanding of the streaming.

                   

                  Regards,

                  Yashwant

                  • 6. Re: CX3 non-UVC buffer size customization
                    NiCo_4789341

                    Hi Yashwant,

                     

                    sorry for my belated reply, it took some time to make some more in-depth tests.

                     

                    Further analysis confirms that the pc-A is more stable since when you start the stream and no action takes place it can potentially continue indefinitely. However, it also stops streaming if any CPU greedy action takes place (for example starting a web-browser).

                     

                    In the end, both pc-A and pc-B suffer from the same problem. Both the machines are equipped with Windows 10, updates installed.

                     

                    When the stream stops the UART message is: CommitBuffer Failure: 47

                     

                    Wireshark traces shows a regular sequence of host request and replies:

                    32938    87.004224    host    3.1.3    USB    27    URB_BULK in

                    32939    87.008248    3.1.3    host    USB    524315    URB_BULK in

                     

                    packets sequence is  6x 524315 bytes + 1x 334299 bytes

                     

                    then we have the crash sequence:

                    32991    87.070368    3.1.3    host    USB    524315    URB_BULK in

                    32992    87.070552    3.1.3    host    USB    8219    URB_BULK in               // an extra, small-sized packet?  -> host

                    32993    87.070552    host    3.1.3    USB    27    URB_BULK in

                    32994    87.070636    host    3.1.3    USB    27    URB_BULK in

                    32995    88.571234    host    3.1.3    USB    27    URB_FUNCTION_ABORT_PIPE

                    32996    88.571322    3.1.3    host    USB    27    URB_BULK in

                    32997    88.571368    3.1.3    host    USB    27    URB_BULK in

                    [..]

                    33011    88.571958    3.1.3    host    USB    27    URB_BULK in

                    33012    88.571996    3.1.3    host    USB    27    URB_FUNCTION_ABORT_PIPE

                    33013    88.572079    host    3.1.3    USB    27    URB_BULK in

                    33014    88.572140    host    3.1.3    USB    27    URB_BULK in

                    33028    88.575098    host    3.1.3    USB    27    URB_BULK in

                    [..]

                    33029    90.075203    host    3.1.3    USB    27    URB_FUNCTION_ABORT_PIPE

                     

                    strange thing is that when the commit buffer failure is detected USB is NAKed and flushed and everything else is restarted, DMA, GPIF statemachine, sockets ecc..

                    Nevertheless i can see that DMA buffer are produced but never consumed and after 8 buffers are produced the commit fails again at 9th.

                     

                    Thank you for your support.