Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

USB superspeed peripherals

LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi all,

I have FX3 firmware that combines AN75779 (modified to receive 32-bit GPIF data) and USB-to-serial. I'm using SuperSpeedKit connected to Zeadboard which sends 120fps 800x480 test pattern. I made all required changes in descriptors and both parts seems to work well except that UVC stream stucks after several seconds of video capture.

By "stucks" I mean that:

1) threads stop running so that I don't see "UVC: Completed ..."  message anymore

2) If I use on-board debugger, debug session also stops responding at all

3) Capture software (Virtualdub/VLC) stop responding as no USB request are processed

Couple additional notes:

1) GPIF SM seems to continue to work because I toggle GPIO from GPIF callback and I can see it in scope.

2) ARM error handlers are not called (put there GPIO toggle also) so it's not CPU issue or memory leak

3) Suspend event not issued for no reason. I do LPM disable on UVC start and enable on UVC stop and return true in LPM CB exactly as in AN75779

Will greatly appreciate for any help

0 Likes
1 Solution
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

Thanks for patch. Now image is not corrupted although at least 2 frames were lost

Here is the output:

               ...

Frames done 49677. Limit reached 0 times

Frames done 49795. Limit reached 0 times

Frames done 49913. Limit reached 0 times

Frames done 50031. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50132 ========

Frames done 50132. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50135 ========

Frames done 50135. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50135 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) ad 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Evs done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 50136 ========

Frames done 50136. Limit reached 0 times

Frames done 50253. Limit reached 0 times

Frames done 50371. Limit reached 0 times

Frames done 50489. Limit reached 0 times

Frames done 50607. Limit reached 0 times

...

Best regards,

Leonid

View solution in original post

0 Likes
46 Replies
YashwantK_46
Moderator
Moderator 100 solutions authored 50 solutions authored 50 likes received
Moderator

Hello,

I can see that you are using 3 threads at once and since when the application is struck and all the threads stop, we need to see which thread is being currently processed to understand what is being struck.

So, please include debug prints in all the 3 threadentry functions at the starting to see which thread is being executed at a certain point of time.

Also, can you please confirm if you have changed the DATA_COUNT_LIMIT and ADDR_COUNT_LIMIT values in the GPIF state machine according to your buffer value and GPIF bus width?

The formula to update the buffer count value is as follows:
pastedImage_0.png

According to your firmware, buffer size is 16KB and 32-bit bus width, so the count value would be:

count = ((((16*1024)-16)/4) - 1) = 4091

Please add the debug print as follows and please share the entire debug log with me so that i can see the point at which the thread is getting struck.

Regards,

Yashwant

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi,

Yes, GPIF is configured as it should be. As I wrote I have video successfully received from FX3 by PC.

Problem is that FX3 hangs after a while.

I added debug messages to all three threads and changed EventGet parameter from WAIT_FOREVER to 1s so that the print stuff:

  • Thread UVCAppThread_Entry prints "UVCAppThread_Entry"
  • Thread UVCAppEP0Thread_Entry prints "UVCAppEP0Thread_Entry"
  • Thread USBUARTAppThread_Entry prints "UVC: Completed..." statistics message

However it's still strange for me that when this "stuck" happens even debugger stops responding

Attaching full log and updated sources.  As you may see all three threads stopped working.

Regards,

Leonid

0 Likes
YashwantK_46
Moderator
Moderator 100 solutions authored 50 solutions authored 50 likes received
Moderator

Hello Leonid,

Can you explain as to why you are using 3 threads in your UVC application?

Please elaborate.


Also, can you please test with the default UVC example project available with the app note AN75779 and see if you still see the issue?

Is there a possibility for you to decrease the number of threads and then test and see if you notice any hanging issues in the firmware?

Is the issue of freezing random or always happens at an exact point in the firmware execution?

Regards,

Yashwant

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Yashwant,

In my firmware I combined two Cypress examples:

Here is my thread functionality:

1) UVCAppThread_Entry handles UVC related requests (start/stop/suspend/dma reset) (as in AN75779)

2) UVCAppEP0Thread_Entry handles video EP requests (control/stream) (as in UVC+USB2UART example)

3) USBUARTAppThread_Entry handles UART dma wrap-ups. (as in UVC+USB2UART example)

AN75779 works perfect in my setup but it doesn't help to solve this issue

I already tried to reduce number of threads. I combined functionality of UVCAppThread_Entry and UVCAppEP0Thread_Entry but it still hangs

Freezing is random, but I looks like if I do many UVC start/stop it will hang sooner

Best regards,

Leonid

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi,

Another thing - I noticed that when in hanged state USB2UART DMA continue to work. So I guess it's just ThreadX who stopped working

Best regards,

Leonid

0 Likes
YashwantK_46
Moderator
Moderator 100 solutions authored 50 solutions authored 50 likes received
Moderator

Hello Leonid,

I already tried to reduce number of threads. I combined functionality of UVCAppThread_Entry and UVCAppEP0Thread_Entry but it still hangs

--> Does this mean that you currently have 2 threads in your application and it still hangs?

I noticed that when in hanged state USB2UART DMA continues to work. So I guess it's just ThreadX who stopped working.

--> Can you please elaborate as to what you meant by DMA continue to work and can you confirm as to how you confirmed it?

As an experiment, is it possible for you to include the functionality of UART DMA wrap-ups into the UVCAppThread_entry and see if you are able to see the freezing issue still happening?

Regards,

Yashwant

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi, Yashwant

    

> Does this mean that you currently have 2 threads in your application and it still hangs?

     Yes, exactly

> Can you please elaborate as to what you meant by DMA continue to work and can you confirm as to how you confirmed it?

     USB2UART uses two DMA channels - auto (usb3 -> UART) and manual (uart -> USB3). The Auto one continue to work during hanging      state, while manual one that depends on thread stops working.

> As an experiment, is it possible for you to include the functionality of UART DMA wrap-ups into the UVCAppThread_entry and see if you are able to see the freezing issue still happening

     Looks like we think the same way - I already tried it yesterday. So now I have one thread and it still hangs - no video, no uart-to-usb3, no debugger

Best regards,

Leonid

0 Likes
YashwantK_46
Moderator
Moderator 100 solutions authored 50 solutions authored 50 likes received
Moderator

Hello Leonid,

Thank you for the confirmation regarding the firmware modifications done.

"USB2UART uses two DMA channels - auto (usb3 -> UART) and manual (uart -> USB3). The Auto one continue to work during hanging      state, while manual one that depends on thread stops working."

--> Can you please confirm as to how you got to know that AUTO channel was working while the MANUAL channel stopped working?

Can you please share you original firmware so that we can test it on our end and see if we can reproduce the issue here?

If you have any confidential sensor settings, you can exclude it out of your firmware, we will replace them with our default sensor settings and test it.

Regards,

Yashwant

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Yashwant,

Can you please confirm as to how you got to know that AUTO channel was working while the MANUAL channel stopped working?

     It's very simple - I have two serial terminals open. One is connected to UART pins of FX3, another one is connected to USB3 connector. During "hanging" stage when I send something through USB3 I still see data on UART as this channel is auto. But opposite direction doesn't work because it's manual and require thread to be running.

I'm attaching my full sources including GPIF designer files. There are no any confidential things in code because after all it's just two Cypress examples combined.

Please, note that I'm using 32-bit GPIF input with 100MHz clock on it.

Thanks,

Leonid

0 Likes
YashwantK_46
Moderator
Moderator 100 solutions authored 50 solutions authored 50 likes received
Moderator

Hello Leonid,


Thank you for sharing your firmware.


I have a doubt about the uart_printf function in your firmware.

Where will this function print the data on?

And why are using uart_printf() function instead of the CyU3PDebugPrint() API in your firmware?

Regards,
Yashwant

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi, Yashwant

This function is not used because #define DEBUG_UART is commented

Best regards,

Leonid

0 Likes
YashwantK_46
Moderator
Moderator 100 solutions authored 50 solutions authored 50 likes received
Moderator

Hello Leonid,

This function is not used because #define DEBUG_UART is commented

--> Are you enabling it when you are trying to debug the board? Or is it commented even then?

Also,

With the above firmware, did you see video stream atleast initially for some time?

If yes, can you please try below in the above firmware:

  1. Increase the stack size for the thread.
  2. Decrease buffer size for chHandleUSBSerial_OUT channel to 16 bytes.
  3. Remove DmaChannelSetWrapUp for chHandleUSBSerial_OUT channel.

Please try the following and get back to me with the results.

Regards,

Yashwant

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Yashwant,

--> Are you enabling it when you are trying to debug the board? Or is it commented even then?

Yes, I uncomment it just for debug. It doesn't have impact on this issue.

--> With the above firmware, did you see video stream atleast initially for some time?

Yes, I see video for several seconds (usually about 10 seconds) and then it hangs

1. Increased stack size form 0x1000 to 0x4000 - still hangs

2. Decreased buffer size to 16b - still hangs

3. Removed DMA wrap-ups - still hangs

Best regards,

Leonid

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Yashwant,

Are there any updates?

Were you able to reproduce the issue?

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

The reason why we were asking about uart_printf/ about debugging is that: Both the channel chHandleUSBSerial_IN and uart_printf() will be accessing UART Tx. We wanted to know if this is causing the problem.

As per your comment in post 13, it looks like it is taken care that both are not present at the same time. Please confirm.

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

Yes, I confirm that. uart_printf is not used together with DMA UART config.

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Okay. Can you please attach your latest code that you are testing so that we are looking at the same files.

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Here it is

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

In CyFxUvcApplnDmaCallback() Is Commitbufferfailure seen at the time of issue? - You can use CyU3PDeviceReset(CyFalse) to check it.

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

I guess not, because CY_FX_UVC_DMA_RESET_COMMIT_BUFFER_FAILURE event is never produced.

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi, Hemanth

I started to check callbacks behavior while saw some interesting things.

Here is what I did:

1. In order to check I uncommented DEBUG_ART define to use uart_printf function. Of course in this case whole USB2UART part of firmware is disabled.

2. Surprisingly after several minutes of normal streaming UVC DMA callback generates one buffer failure with well-known status 71 (CY_U3P_ERROR_INVALID_SEQUENCE) and of course UVC restarts causing capture software to hang.  I added clause in order to ignore this error and not to restart UVC part. In that case streaming continues but image becomes corrupted.

3. In order to handle CY_U3P_ERROR_INVALID_SEQUENCE properly I implemented silent DMA reset function described in KBA218830 and recorded video for 30 minutes.

4. During this period CY_U3P_ERROR_INVALID_SEQUENCE occurs several times and each time CyU3PGpifSMStart returns 0x44 (CY_U3P_ERROR_NOT_CONFIGURED) but streaming continues, also image becomes corrupted and returns to normal several times.

To sum up: 

  • Thanks to your suggestions I narrowed the problem to CY_U3P_ERROR_INVALID_SEQUENCE and its handling is done exactly as described in KBA218830. So no more hanging.
  • There are still some problems with image corruption when invalid sequence error happens.
  • I’m attaching my latest sources

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

Thank you for the files.

Please test the attached project and let me know your observations.

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

Still the same - once in a while "invalid sequence" happens and then image corrupts.

If it helps I have the following output:

...

               UVC: Completed 2948 frames and 44 buffers

               UVC: Completed 3066 frames and 38 buffers

UVC: Completed 3066 frames and 38 buffers

UVC: Completed 3184 frames and 40 buffers

======== DMA Reset Event: Commit buffer failure (47) ========

CyU3PGpifSMStart  = 68

UVC: Completed 3195 frames and 24 buffers

               UVC: Completed 3312 frames and 0 buffers

               UVC: Completed 3430 frames and 0 buffers

...

My recording is 1:30 (10757 frames) and image got corrupted from frame 3796 to 4916.

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

GpifDisable() and CyU3PGpifSMStart() are missing as mentioned in KBA218830.

Can you please include and try.

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

Sorry for that.

I added GpifDisable and now CyU3PGpifSMStart doesn't produce error 0x44

I also recorded 2302s of video and invalid sequence occurred only once and did not affected image at all.

At the end serial port log reported "UVC: Completed 276128 frames" while VirtualDub received only 158585 frames

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

Can you make the following changes and try:

1. Reset the gl_commit_count variable in AppStop(), reset_dma_in_case_of_invalid_sequence().

2. Change

if (gl_commit_count == (2* CY_FX_UVC_STREAM_BUF_COUNT))

            break;

to

if (gl_commit_count == ((2* CY_FX_UVC_STREAM_BUF_COUNT) - 1))

{

           gl_commit_count_limit_reached = 1;

            break;

}

3. check whether this variable is set if at all you get commit buffer failure after above change.

If you are still getting it, please try with different video player also to check howmany frames are received. Howmuch is your fps?

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

I send 800x482x120fps stream to FX3

I made suggested changes except instead of gl_commit_count_limit_reached = 1; I wrote gl_commit_count_limit_reached++;

And I reset it in CyFxUVCApplnStart()

Apparently, problem is in destination media type: I used external SDD connected through USB3 before. Now when I switched to local system hard drive recording is good - image is not corrupted and number of frames corresponds to one that I see in serial output but "invalid sequence" occurred once and gl_commit_count_limit_reached jumped to 22 between to sequential lines of output:

               UVC: Completed 27690 frames and 4 buffers. Limit reached 0 times

               UVC: Completed 27809 frames and 4 buffers. Limit reached 0 times

               UVC: Completed 27928 frames and 8 buffers. Limit reached 0 times

               ======== DMA Reset Event: Commit buffer failure (47) ========

               UVC: Completed 27964 frames and 49 buffers. Limit reached 2 times

               UVC: Completed 28066 frames and 0 buffers. Limit reached 21 times

               UVC: Completed 28184 frames and 6 buffers. Limit reached 21 times

               UVC: Completed 28303 frames and 4 buffers. Limit reached 21 times

               UVC: Completed 28422 frames and 8 buffers. Limit reached 21 times

But this happened at the end of recording when I had only ~2 GB left on drive. I have feeling that probably windows did something that slowed file recording and that caused slowing reception of frames and caused "invalid sequence".

So I'll try to free up some more space and make longest possible recording.

Best regards,

Leonid

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

After several checks I might say that "invalid sequence" still occurs regardless of recording media and at random time from start of recording

Couple time it caused recording to stop at all. gl_commit_count_limit_reached keeps increment regardless of "invalid sequence" error

I'm attaching my latest sources

Best regards,

Leonid

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

I lowered video stream FPS to 30 and here is my log for 300s of recording to local system HDD:

*** CyFxUVCApplnStart ***

UVC: Completed 0 frames and 0 buffers. Limit reached 0 times

UVC: Completed 30 frames and 0 buffers. Limit reached 0 times

UVC: Completed 59 frames and 0 buffers. Limit reached 0 times

UVC: Completed 89 frames and 0 buffers. Limit reached 0 times

UVC: Completed 118 frames and 0 buffers. Limit reached 0 times

UVC: Completed 147 frames and 4 buffers. Limit reached 0 times

UVC: Completed 177 frames and 0 buffers. Limit reached 0 times

UVC: Completed 206 frames and 0 buffers. Limit reached 0 times

UVC: Completed 236 frames and 0 buffers. Limit reached 0 times

UVC: Completed 265 frames and 0 buffers. Limit reached 0 times

UVC: Completed 295 frames and 0 buffers. Limit reached 0 times

UVC: Completed 324 frames and 0 buffers. Limit reached 0 times

UVC: Completed 353 frames and 18 buffers. Limit reached 0 times

UVC: Completed 383 frames and 0 buffers. Limit reached 0 times

UVC: Completed 412 frames and 0 buffers. Limit reached 0 times

UVC: Completed 442 frames and 0 buffers. Limit reached 0 times

UVC: Completed 471 frames and 0 buffers. Limit reached 0 times

UVC: Completed 501 frames and 0 buffers. Limit reached 0 times

UVC: Completed 530 frames and 0 buffers. Limit reached 0 times

UVC: Completed 559 frames and 18 buffers. Limit reached 0 times

UVC: Completed 589 frames and 0 buffers. Limit reached 0 times

UVC: Completed 618 frames and 0 buffers. Limit reached 0 times

UVC: Completed 648 frames and 0 buffers. Limit reached 0 times

UVC: Completed 677 frames and 0 buffers. Limit reached 0 times

UVC: Completed 707 frames and 0 buffers. Limit reached 0 times

UVC: Completed 736 frames and 0 buffers. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (0x47) ========

UVC: Completed 760 frames and 27 buffers. Limit reached 2 times

UVC: Completed 769 frames and 0 buffers. Limit reached 40 times

UVC: Completed 796 frames and 0 buffers. Limit reached 43 times

UVC: Completed 826 frames and 0 buffers. Limit reached 43 times

UVC: Completed 849 frames and 1 buffers. Limit reached 51 times

UVC: Completed 879 frames and 1 buffers. Limit reached 51 times

UVC: Completed 908 frames and 1 buffers. Limit reached 51 times

UVC: Completed 937 frames and 29 buffers. Limit reached 51 times

UVC: Completed 967 frames and 1 buffers. Limit reached 51 times

UVC: Completed 996 frames and 1 buffers. Limit reached 51 times

UVC: Completed 1026 frames and 1 buffers. Limit reached 51 times

...

Looks like the issue is not related to drive IO speed.

BTW, image is corrupted starting from frame 825 till the end

Best regards,

Leonid

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

After several days of various testing I can conclude that:

  • image got corrupted even on 30fps stream on random time but mostly within 25 minutes of recording regardless of "invalid sequence" error
  • disabling DMA channel cache makes things better
  • no channel errors or other events (CY_U3P_DMA_CB_xxx) occur when image is corrupted
  • it's better to ignore "invalid sequence" then reset DMA/GPIF
  • limiting number of buffers processed in DMA callback doesn't solve the issue

Could you please recommend something?

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

In all the firmware version you have shared I had been seeing status = CyU3PDeviceCacheControl (CyTrue, CyFalse, CyFalse); -> which shows DMA cache handling disabled.

Can you please let me know when you have enabled it?

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

I'm not enabling cache. I added the following lines in CyFxUVCApplnInit

apiRetStatus = CyU3PDmaMultiChannelCacheControl(&glChHandleUVCStream, CyFalse);

if (apiRetStatus != CY_U3P_SUCCESS)CyFxAppErrorHandler(__LINE__,apiRetStatus);

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

In dma callback, -> if (gl_commit_count == (2* CY_FX_UVC_STREAM_BUF_COUNT)) condition is better than

if (gl_commit_count == (2* CY_FX_UVC_STREAM_BUF_COUNT)-1).

So, can you please revert back and along with it reset gl_commit_count_limit_reached to 0 in reset_dma_in_case_of_invalid_sequence().

Increase the DMA buffer size little more than the current value.

With these changes let me know if you get commit buffer failure and if yes, then please let me know the behavior of gl_commit_count_limit_reached variable.

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

With if (gl_commit_count == (2* CY_FX_UVC_STREAM_BUF_COUNT)) condition and DMA buffers increased to 6 I have the following for the 120fps:

Frames done 56199. Limit reached 0 times

Frames done 56317. Limit reached 0 times

Frames done 56435. Limit reached 0 times

Frames done 56553. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 56594 ========

Frames done 56594. Limit reached 0 times

Frames done 56692. Limit reached 19 times

Frames done 56810. Limit reached 19 times

Frames done 56928. Limit reached 19 times

Frames done 57046. Limit reached 19 times

Frames done 57164. Limit reached 19 times

According to recorded file one video frame was lost (I guess because  of DMA reset) but  there are no damaged frames.

Best regards,

Leonid

0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

And this I have for the 30 fps:

Frames done 14890. Limit reached 0 times

Frames done 14919. Limit reached 0 times

Frames done 14948. Limit reached 0 times

Frames done 14978. Limit reached 0 times

Frames done 15007. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 15014 ========

Frames done 15014. Limit reached 0 times

Frames done 15043. Limit reached 2 times

Frames done 15072. Limit reached 2 times

Frames done 15102. Limit reached 2 times

Frames done 15131. Limit reached 2 times

But in this case image became corrupted and never returned to normal

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

Please note that commit buffer failure occurs when the data throughput from the GPIF interface is in such a way that all the DMA buffers gets overflowed. So, consider increasing the horizontal blanking to reduce the throughput on GPIF side (to maintain the same frame rate you can reduce vertical blanking accordingly).

Regards,

Hemanth 

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

As I wrote above problem occurs also on 30fps.

Having resolution to be 800x482, and GPIF working on 100MHz here is my blanking values :

  • 120 fps: horizontal = 1315 clocks, vertical = 5388 clocks
  • 30 fps: horizontal = 6490 clocks, vertical = 5863 clocks

I assume that such blanking values are more than enough for not having overflow.

Anyway your suggestion leads us to my earlier question which I asked in other topic several months ago: what are minimum requirements for pause between lines and frames (blanking) on GPIF interface? I did not found this information in FX3 datasheet

Best regards,

Leonid

0 Likes
Hemanth
Moderator
Moderator First question asked 750 replies posted 500 replies posted
Moderator

Hi Leonid,

If you are using FX3 SDK 1.3.4, then 500uS vertical blanking should be sufficient. But we have observed that it works till 300uS. In your case, it looks like vertical is less - 53/58 uS. Horizontal blanking looks fine - there is no restriction as such - but the more it is, the less is the throughput requirement on Host side.

Regards,

Hemanth

Hemanth
0 Likes
LeGa_3963206
Level 4
50 replies posted 25 replies posted 10 replies posted
Level 4

Hi Hemanth,

I doubt that issue is related to short blanking.

Here is what I have now:

FPS306090120
H Blank (us)11111111
V Blank (us)26092942638701092

And yet:

30 FPS: (no "invalid sequence", image corrupted):

...

Frames done 25617. Limit reached 0 times

Frames done 25647. Limit reached 0 times

Frames done 25671. Limit reached 7 times

Frames done 25701. Limit reached 7 times

Frames done 25730. Limit reached 7 times

...

120 FPS: (""invalid sequence" and image corrupted):

...

Frames done 8849. Limit reached 0 times

Frames done 8967. Limit reached 0 times

Frames done 9085. Limit reached 0 times

======== DMA Reset Event: Commit buffer failure (47) after frame 9135 ========

Frames done 9135. Limit reached 0 times

Frames done 9183. Limit reached 97 times

Frames done 9299. Limit reached 101 times

Frames done 9417. Limit reached 101 times

Frames done 9519. Limit reached 123 times

Frames done 9637. Limit reached 123 times

...

Best regards,

Leonid

0 Likes