1 2 Previous Next 18 Replies Latest reply on Oct 6, 2020 9:08 PM by RashiV_61

    CX3: moved to 1_3_4 sdk, bulk endpoint stopped working

    EtWh_2921621

      we moved from 1_3_3 to  1_3_4,and the bulk endpoint stopped working. At least, how we are calling it. On the PC side, we call CreateFileW() on the device's path, then we call WinUsb_Initialize( ) on the file handle, then use WinUsb() functions to get the pipes, then use WinUsb_ReadPipe and WinUsb_WritePipe to read and write to the CX3. This used to work, now does not. The CX3, from the debug UART, doesn't even see the DMA callback.

       

      Can't use the CCyUsbDevice() stuff (I guess) because when the firmware is loaded onto the CX3, it switches to being a video capture device, and CCyUsbDevice doesn't seem to enumerate or talk to those types of devices!

       

      Not sure how to debug this issue or work around it. Suggestions? Anybody else see this? I can post the descriptors and the endpoint creation logic, if necessary.

        • 1. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
          RashiV_61

          Hello,

           

          - Please let me know if the firmware implementation is the same as mentioned in response 8 of this thread https://community.cypress.com/message/251589?et=watches.email.thread#251589 

          - Let me know if the device enumerates well (with the additional endpoints) after changing the SDK version to 1.3.4

          - Please explain the flow of the firmware. When is the DMA channel corresponding to the above-mentioned USB pipe created?

          -  Please try adding this API in the firmware to CyU3PUsbRegisterEpEvtCallback to receive the endpoint event callback. This will help in debugging the problem.

          -  From the response in the above-mentioned thread, I see that only one BULK Endpoint is configured and the DMA channels are two: one IN and one OUT. Please share the complete firmware implementation for us to check.

          - Please share the UART debug prints

           

           

          Regards,

          Rashi

          • 2. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
            EtWh_2921621

            Hi. I am really in a critical time crunch. I am going to send this right away. Can I send you a zip? I’m not sure if I am allowed to publicly post the entire firmware. My email is efrazer@micro soft.com, minus the space... I will be working on this all night.

            • 3. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
              RashiV_61

              Hello,

               

              I was able to reproduce the problem you were facing.

               

              Please try calling WinUSBDMAInitialize() after the USB event CY_U3P_USB_EVENT_SETCONF. After these modifications, I was able to send 4096 bytes to the firmware through BULK OUT (0x06) after building the firmware with SDK 1.3.4.

               

              Regards,

              Rashi

              • 4. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                EtWh_2921621

                Wow! Thanks! (?)

                First of all - how do I do that?

                Secondly - why does this work, and is this sequence of steps shown in one of the examples? Were we missing something important and forgot it?

                • 5. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                  EtWh_2921621

                  likewise, where is the place I should add RegisterEpEvtCallback? at what spot in the code would it be appropriate?

                  • 6. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                    EtWh_2921621

                    I'm guessing I call RegisterEpEvtCallback after calling DmaChannelCreate and SetXfer. One thing that is puzzling me in the code I inherited is seemingly-random sleeps between calls to 'let things settle'. Glad those wait calls aren't in this particular piece of code. I don't know which events to look for to help debug the problem. All events? Ok, I will try that.

                     

                    ... Yep, that seems to have fixed it!!! I am comparing this solution to others out there in the firmware examples directory. I NEVER would have guessed to do it this way. Thanks! By the way, how did you even guess to put the DmaInitialize( ) call after the SETCONF? It really bothers me these random sleeps to 'make the timing work'. As an engineer who likes to write clean code, it is against my morals to put in random sleep waits. :-)

                     

                    It's been running for a while already. Much longer than it normally runs w/o hanging.

                     

                    **** MSRVideoAR_PersistentSettingsRead ****

                      I2C access - dev: 0xa4, address: 0x0, size: 79, pages: 0x1.

                    Persistent Settings Read, red gain = 1325

                    Sensor Initialization

                    Writing Configuration Settings:

                    **** CyCx3UvcAppInit BEGIN Setting USB Descriptors ****

                    **** CyCx3UvcAppInit END Setting USB Descriptors ****

                    **** CyCx3UvcAppInit CONNECTING TO USB ****

                    **** CyCx3UvcAppInit CONNECTION TO USB COMPLETE ****

                    CyCx3UvcAppUSBSetupCB CY_U3P_USB_VENDOR_RQT = 26

                    CyCx3UvcAppUSBSetupCB Microsoft OS Descriptor Set REQ

                    **** WinUSBDMAInitialize EXIT ****

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    StpCB:In SET_FTR Configured=1

                    #### OnWinUSBDMACompletionCallback RECV ####

                    Processing command 30

                    CX3_USB_GETINFO_EVENT

                    #### OnWinUSBDMACompletionCallback RECV ####

                    Processing command 100

                    CX3_UVC_VS_COMMIT_CONTROL

                    CyCx3UvcAppImageSensorSetVideoResolution 7

                    USBStpCB:Xres = 0x0

                    USBStpCB:XSHUTDOWN = 0x0

                    CyCx3_ImageSensor_Set_1920x1440x8bitx90FPSResolution

                    Writing Configuration Settings:

                    **** Read in VTS=1499, HTS=889

                    **** sending persistent settings to the sensor: gain, exposure, etc ***

                            Set 10 to 888

                    HandleSetAValue32, command = 12, value = 19694

                    **OV4689_SetExposure 19694**

                            Set 24 to 1325

                            Set 26 to 1024

                            Set 28 to 1626

                    ****CyCx3UvcAppStop, already stopped, returning

                    UvcAppHandleSetCurReq, wValue = VS_COMMIT_CONTROL, stopping and starting UvcApp

                    ****CyCx3UvcAppStart ENTRY****

                    ****CyCx3UvcAppStart EXIT, sys clk freq = 403200000****

                    #### OnWinUSBDMACompletionCallback RECV ####

                    Get VTS = 1499, HTS=889

                    Processing command 31

                    #### OnWinUSBDMACompletionCallback RECV ####

                    Processing command 30

                    CX3_USB_GETINFO_EVENT

                    #### OnWinUSBDMACompletionCallback RECV ####

                    Processing command 100

                    Tick - fps = 91, frames=1556, consumed=1556, dma buffers out = 1, frmErr=0, crc=0, mdlErr=0, ctlErr=1, eid=0, recr=0, unrecr=0, recSyncErr=0, unrecSyncErr =0, inWhileLoopTooLong = 0, gGotErr0x47 = 0

                    • 7. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                      EtWh_2921621

                      well, I thought moving to 1_3_4 was going to be the solution, but unfortunately, it's not. It still randomly locks up after 5-10 minutes of running. trouble is, I don't know enough about windows usb to understand why it locks up, or how to debug it. It locks up after 5 minutes, so it's near impossible to debug with a USB hardware debugger. I'm fairly certain it's a bug between the CX3 and the Windows machine. I've turned off ALL the low power management code in our firmware. Is that okay? Or will windows "get upset" and eventually trash the pipeline because of it? I'm not quite sure how to debug what's going on - I can't add uart messages to the cameras (there are 2 of them), they're embedded into the headset. Only thing I could do is add custom debug messages back and forth between the PC and the firmware, over that USB channel you fixed...

                       

                      I can't be the only person trying to send out 1920x1440x90Hz with 2 channels over USB, right? There are other people testing high-bandwidth USB 3.0 video capture, right?

                       

                      I'm wondering if I should go back to the example firmware and start over from scratch...

                      • 8. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                        EtWh_2921621

                        i don't know anything about this GPIF statemachine waveform thing... I see it in our file cycx3gpifwaveform.h... for the CX3, isn't the waveform to capture incoming video pretty much the same for any sensor? If it captures at all, doesn't that mean the state machine is pretty much good? Should I be able to steal the one from the 75779 and that should work?

                        • 9. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                          RashiV_61

                          Hello,

                           

                          You can refer to the firmware in SDK 1.3.4 where the FX3 will enumerate as vendor device. In this firmware, the DMA channels are created after the CY_U3P_USB_EVENT_SETCONF event. Please refer to bulksrcsink firmware if the SDK.

                           

                           

                          likewise, where is the place I should add RegisterEpEvtCallback? at what spot in the code would it be appropriate?

                          >> Please refer to bulksrcsink example of the SDK which implements CyU3PUsbRegisterEpEvtCallback API

                           

                          It still randomly locks up after 5-10 minutes of running. trouble is, I don't know enough about windows USB to understand why it locks up, or how to debug it.

                          >> Please let me know what exactly happens when you start streaming after opening the host application. Are you getting the debug prints? If yes, please share the debug prints

                           

                           

                          I can't be the only person trying to send out 1920x1440x90Hz with 2 channels over USB, right? There are other people testing high-bandwidth USB 3.0 video capture, right? I'm wondering if I should go back to the example firmware and start over from scratch...

                          >> From two channels you mean the 1) streaming channel 2) the channel for vendor interface. Please try disabling the second channel / or the vendor interface and enable only the streaming channel (UVC interface) and let me know if the streaming is proper.

                           

                          i don't know anything about this GPIF statemachine waveform thing... I see it in our file cycx3gpifwaveform.h... for the CX3, isn't the waveform to capture incoming video pretty much the same for any sensor? If it captures at all, doesn't that mean the state machine is pretty much good? Should I be able to steal the one from the 75779 and that should work?

                          >> CX3 has a Fixed function GPIF state machine. We do not recommend changing this state machine. To check the if the video data is coming proper to CX3 you can probe the test points as mentioned in Q10 of this KBA. CX3 Hardware: Frequently Asked Questions - KBA91295

                          Also, please check the number of producer events for one frame. This will help in debugging the problem. Please try doing these tests after disabling the vendor interface (second DMA channel)

                           

                          Regards,

                          Rashi

                           

                           

                           

                           

                           

                           

                           

                          • 10. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                            EtWh_2921621

                            No I mean I have two separate USB 3.0 hosts, and I'm running 1920 x 1080 x 90fps x RAW8 over each one. I reduced the frame rate to 45FPS and it's been running for over 2 hours w/o hanging, whereas when I run it at 90 FPS it hangs within 5 minutes.

                             

                            I'm not worried that the frames aren't coming in right from the OV sensor. I'm *sure* the problem is a DMA issue between the PC and the CX3.

                             

                            If the CX3 has a fixed GPIF statemachine, why is it defined in this firmware source code I inherited, and why is it in the 75779 example? Either way, if it's true, and there ISN'T a waveform I need to set on the CX3, all the better. Then I don't need to fool around with the GPIF designer tool & stuff. Less to learn.

                             

                            How in the world would I be able to know the # of producer events for one frame? you mean for just one frame, or an average of producer events over N frames delivered? Any particular type of producer event? :-) I don't even know what a producer event is or how many types there are, or what the #'s should be. How many producer events SHOULD there be per frame?

                             

                            I'm getting the idea 1920 x 1440 x 90 FPS x 2 channels (left and right) is simply too much for the USB 3.0 bus on the PC to handle utterly consistently. I personally think the PC doesn't emit enough read tokens to the CX3 and after a bit, it simply gives up and silently kills the stream.

                             

                            I'd love it if somebody at Cypress (or elsewhere) got a sensor chip set up at 1920 x 1440 x 90 FPS (or equiv) and demonstrated to themselves that they could blast 1 or better yet 2 of those streams to a PC and have it never hang. Do you at Cypress have dev boards with sensor chips on them that are programmable to different resolutions? That can go as high as 1920 x 1440 x 90 FPS? I'd love to see somebody else accomplish that w/ firmware. Then I'd love to have a good look at that firmware. I'd even see if i could get my boss to put a 'bounty' on that goal. :-)

                            • 11. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                              RashiV_61

                              Hello,

                               

                              No I mean I have two separate USB 3.0 hosts, and I'm running 1920 x 1080 x 90fps x RAW8 over each one.

                              >> In the firmware you shared I could see just a single DMA channel i.e. from 2 PIB sockets to UIB/USB socket. How are you sending data to two hosts from a single endpoint? Please share a block diagram of your hardware setup so that we can debug the problem

                              It seems that the problem is due to the video bandwidth on USB 3.0. Please let me know if you get the commit buffer failures when the video is being streamed at 90 fps? Can you share the UART debug prints for this case?

                              >> Instead of streaming it on two hosts please try streaming the video at 90 fps with one channel and let me know the results

                               

                              How in the world would I be able to know the # of producer events for one frame? you mean for just one frame, or an average of producer events over N frames delivered? Any particular type of producer event? :-) I don't even know what a producer event is or how many types there are, or what the #'s should be. How many producer events SHOULD there be per frame?

                              >> The frame ends with a partial buffer. So as soon as a partial buffer is committed in the DMA callback 1 frame can be counted.

                              CY_U3P_DMA_CB_PROD_EVENT event occurs when the DMA buffer is completely filled with the video data. To check if the video data from the MIPI receiver is proper we can check the DMA buffers filled

                              For example Frame size: 1920 *1440* 1(RAW8) byte = 2764800bytes and the DMA buffer size is 24 KB(0x6000) then for 1 frame 112 full buffers and 1 partial buffer will be needed.

                              The CY_U3P_DMA_CB_PROD_EVENT can be tracked using a variable and get the prints in for{} loop. The variable needs to be reset when one frame is completed. In this way, we can confirm if the data on CX3 is coming properly.

                               

                               

                              For some reference designs, you can refer to

                              Denebola kit : https://www.cypress.com/documentation/development-kitsboards/denebola-usb-30-uvc-reference-design-kit-rdk

                              Tania Kit: https://www.cypress.com/documentation/development-kitsboards/tania-cypress-cx3-socionext-isp-reference-design-kit-rdk-du…

                              Ascella kit: https://www.cypress.com/documentation/development-kitsboards/ascella-cypress-cx3-thine-isp-13mp-reference-design-kit-rdk

                               

                              Regards,

                              Rashi

                               

                               

                              • 12. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                                EtWh_2921621

                                I've reduced the frame rate down to 45FPS instead of 90FPS and the 0x47 errors have almost completely went away. Sort of signalling it's a PC issue, not the CX3. Unless for whatever reason, the timing I put into the OV sensor was "more right" than the timing for the 90HZ. But that's sort of unreasonable to think that. I ran into a weird thing today where I DID get a single 0x47 error and it stopped and tried to reset the DMA, but it was that glStopStreaming was set, when there was no way it should have been set, and it just stopped and didn't restart. That implies to me that glStopStreaming got corrupted. I'm debugging it again, printing out the value of glStopStreaming (if it's not 1, I know something bad happened).

                                 

                                Is there a way to check overall memory usage, or to run a quick heap check on the CX3?

                                • 13. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                                  EtWh_2921621

                                  I am seeing 113 produce events per frame, exactly. good call.

                                  • 14. Re: CX3: moved to 1_3_4 sdk, bulk endpoint stopped working
                                    RashiV_61

                                    Hello,

                                     

                                    In the firmware you shared I could see just a single DMA channel i.e. from 2 PIB sockets to UIB/USB socket. How are you sending data to two hosts from a single endpoint? Please share a block diagram of your hardware setup so that we can debug the problem

                                    >> Please let me know this. This will help us to debug the issue faster.

                                     

                                    To reduce the rate at which the data is streaming you can try to increase the Horizontal blanking period. Please increase the Horizontal blanking time as much as you can.  For this, you need to modify the sensor settings as well as the CX3 MIPI receiver settings. Please let me know if this helps.

                                     

                                    glStopStreaming seems to be a global variable that is stored in the data region of the CX3 memory map.The data and bss region used by the application can be found from the .map file which will be found in the debug drop down which is available under the project in project explorer in the EZ USB suite.

                                     

                                    Regards,

                                    Rashi

                                    1 2 Previous Next