13 Replies Latest reply on Aug 24, 2017 4:38 AM by savj

    AN75779 is not STABLE AT ALL !

    admin_1473091

      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.