It will just stop sending data to the host after some time (minutes).
Most of the time i get "Error in multichannelcommitbuffer: Code = 71, size = 3FFF, dmaDone 0-7" error, but sometimes it just stops outputting frames without it (the COM port stops printing the frame numbers, i've even made it just output + or - instead of full frame number in case that was delaying the CPU enough to break it, but no.). Sometimes it is enough to just disconnect/reconnect the video stream in virtualdub/OBS, sometimes the ARM cpu needs a reboot to fix the stall.
And sometimes it does this: https://images.sshnuke.net/2016-01-04_00-38-57.png the clear feature request was initiated by me to try and re-start it, but now its stuck and requires a reboot.
The example is exactly the code with the AN, i just set 32bits to true in the C code, then in the GPIF2 editor made the requested modifications for 32bit operation: counter limits set to 4091. I've also modified the descriptor for 720p60 operation.
The waveforms of FV and LV are as such: https://images.sshnuke.net/2016-01-04_00-41-06.png
FV goes high at the same time as first LV does, to give the ARM CPU as much time to reset DMA and state machine as possible (it is 407uS of LOW value of FV in that screenshot)
This unstable behaviour is quite unacceptable for a 'complete' video solution...and you cannot really debug the GPIF2 state machine/DMA engine, just the ARM cpu, so how does this get fixed into a usable video device ? This is all in Release mode btw, not Debug.
EDIT: This is what it looks like when it requires a ARM reboot to get unstuck: https://images.sshnuke.net/2016-01-04_01-15-41.png
The 'backflow detect' feature does print backflow detected when it stops working, but does nothing to recover from the situation.
USB Analyzer screenshot of one of the situations: https://images.sshnuke.net/2016-01-04_09-13-03.png
It would seem that adding some more code to properly 'unstick' the DMA channels in the case the host could not consume all the data (so that the next frame keeps working) would make this example work properly.
This may require a more complex analysis to find the problem. Can you create a tech support case so that we can debug this?
BTW, please use the latest version of the firmware available on the website to check if it helps.
What is the latest version of the firmware ? I've only been able to find the one attached to the AN page, which doesnt have the GPIF2 designer project in it, and the reply one of the engineers made to a forum thread here asking about the GPIF2 designer project, so it includes that project. The only difference between the two is that CyU3PUsbSendEP0Data calls have 1 as the count in the 2nd one. Both are from 2013 and use the 4.5.1 GCC thing, which i've resolved by just using the .project/.cproject files from the USBVideoBulk sample in the SDK.
EDIT: Just looking at the CFX3 UVC samples, they seem to be way more robust, have a reset timer, and they resume streaming from the thread that last finished, not always from thread 0, so that's nice.
It would be good if the ancient 2013 GPIF2 UVC.c file could be updated to these new standards. I've done so myself, and it works, but i'll see if its more stable than the old uvc.c or not (ported Cx3UvcAS0260 to use GPIF2 instead of MIPI, they were similar, why did it have a different buffer size of 0x2FF0 though, and 12 buffers, not 16.)
EDIT2: It's not more stable. It stops at about the same frequency, and the RESET_TIMER in that firmware does not fix it when it triggers.
My problem was resolved by technical support (they added a reset timer that actually works to the AN UVC sample). I'll ask them to update the AN with the new UVC code if possible.
I don't have the download anymore either because for some reason they remove attachments from their support tickets after they get closed ?!
In the ticket i've asked Cypress to modify the AN with the included more robust code, as it is their right and not mine to redistribute it.
So i suggest that everyone who wants the code make a support ticket in order to get it, if its not already on the AN.
Thanks for share with us the information. Following your advise I'll open a support ticket.
It seems that this kind of "watchdog timer" is included in the CX3 version of UVC but not in the FX3 version.
That one kinda doesnt work, the one i received in my support ticket absolutely does. It has an option of moving all DMA requests outside of the thread and into the interrupt handler too.
After a little research I found that at any given point there is a problem with a death lock which blocks the whole thread. This is the reason why no matter if you reset the channel or whatever, the thread is blocking waiting for a freedom of a mutex (I think is due to race condition, thats the reason why is so random). I can't debug many functions because they are a wrapper in top of ThreadX RTOS and I dont have the source code. Please can you share some guidelines of the solution proposed by cypress to give me an idea of how to drive the situation properly.
The new firmware released on 08/20/2017, i.e. App note rev *I has "commit buffer failure" fixes. Commit buffer failure occurs when Host PC is loaded or it is not fast enough to send IN tokens. In such cases FX3 will exhaust its DMA buffer and it will see a commit buffer failure. Check if it helps/not.