Streaming RAW image data using Cypress Driver part 2

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

cross mob
lock attach
Attachments are accessible only for community members.
ScGr_289066
Level 5
Level 5
100 replies posted 50 replies posted 25 replies posted

Hi All,

I am still having issues using the CX3 RAW transfer firmware from this post: https://community.cypress.com/thread/16971?q=Streaming%20RAW%20image%20data%20using%20Cypress%20driv... and the Cypress library to import RAW video data to the PC.

I see frequent DMA errors (error code 0x47 -- CY_U3P_ERROR_INVALID_SEQUENCE).  The errors are being detected in the CyCx3UvcAppThread_Entry() routine.  Since my original post (), I am concentrating on 5Mp frames @ 14.6 fps which has made the errors more frequent.  I have optimized both the firmware (2000) and software (70) timeouts to the point where streaming can continue sometimes up to tens of minutes.  Further, the system frequently recovers from these errors.  I will see a burst of Steaming stopped/Streaming Started messages then image transfer continues.  Inevitability however, the system will fail resulting in a continuous stream of Streaming stopped/Streaming Started messages without any data transfer.  The only way to recover from this is to reload firmware.

I have experimented adding short delays in the collection thread to see how tolerant it is to Windows induced delays.  Even a delay in collection as short as a millisecond will cause transfer errors and occasionally it causes a complete failure (a continuous stream of Streaming stopped/Streaming Started messages).

Any guidance is appreciated.

Thanks,

Scott

0 Likes
1 Solution

Hello Scott,

I understood that you are streaming the RAW 10 video data. It can be done using the UVC class drivers instead of Vendor class drivers.

In the case of UVC class, the device can mimic the host as UVC class device and send the RAW10 format data.

Here, you need to customize the UVC host application to stream the RAW10 video data.

You may refer to this. This can be applied to FX3 as well.

Streaming RAW10 Format Input Data to 16/24-bit Output Format in CX3 MIPI CSI-2 - KBA224387

I understood that the 31 error triggers when you stream 5MP and the video resolutions are streaming fine with 995 errors. Yes. performing extra operations during image transfer makes this error statistically more likely.

Regards,

Sridhar

Hi Sridhar,

We still frequently encounter error 0x31 that shuts down   imaging.  It

only happens when imaging at full sensor resolution,   5Mp.  We don't see

it at lower resolutions.

The more common error 995(decimal) is common at all   resolutions. It

seems performing any extra operations during image transfer   makes this

error statistically more likely.

So the direct answer to you question is no, these errors   still plague us.

Best,

Scott

View solution in original post

0 Likes
15 Replies
ScGr_289066
Level 5
Level 5
100 replies posted 50 replies posted 25 replies posted

Hi All,

I found this post:

Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830

that seems to describe the issue I am having.  Since the size of the buffers is fixed at 0x6000 for video size reasons, does it make sense to rewrite the firmware to use four of them instead of the two currently in-use?

If it does, how would one go about doing that?

Thanks,

Scott

0 Likes

Hi Scott,

The firmware attached in the "Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830" post is using 4 DMA buffers per GPIF DMA thread and also the size of each buffer is 0x400 * 0x10 = 0x4000. Could you please clarify which firmware you are referring to by saying "the size of the buffers is fixed at 0x6000 for video size reasons, does it make sense to rewrite the firmware to use four of them instead of the two currently in-use". If possible kindly attach your custom firmware so that I can debug.

Thanks & Regards
Abhinav Garg

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Abhinav,

Thanks for your reply.

0 Likes

I have attached my project.

I saw the constant CX3_UVC_DATA_BUF_SIZE and assumed it set the buffer sizes.

I welcome your comments.

Thanks,

Scott

0 Likes

Hi Scott,

-- I saw the constant CX3_UVC_DATA_BUF_SIZE and assumed it set the buffer sizes.

Yes you are right. This parameter sets the buffer size.

--does it make sense to rewrite the firmware to use four of them instead of the two currently in-use?

I looked into the firmware attached, you are still using 4 buffer counts per DMA channel.

You are getting Error Code 71, high chance is the host is not issuing IN tokens fast enough to clear the DMA buffers. Which host application are you using to stream data. Please use Streamer app for this purpose. Control center is used to start streaming the data.

Please share the debug logs.

Thanks & Regards
Abhinav Garg

0 Likes

Hi Abhinav,

So increasing the number of buffers per DMA channel ought to make the firmware more tolerant to momentary pauses of the PC app reading video data?

Thanks,

Scott

0 Likes

Hi Scott,

Yes increasing the number of buffers per DMA channel increases tolerance of firmware against Commit Buffer failures Error 71,  but still host has to issue IN tokens for proper working of firmware.

What do you mean by momentary pauses of the PC app reading video data? Are you facing any frame drops in PC application?

Please answer all the questions in the previous response.

Thanks & Regards

Abhinav

0 Likes

Hi Abhinav,

Normally, the system does capture every frame.  However, multi-tasking being what it is, there are times when the system is busy performing other tasks that will delay data transfer just enough to cause it to fail.  Normally, as the PC idles with the collection app running, collection will proceed for tens of minutes, 10, 20, 30 minutes is not uncommon.  If I interact with the PC while the app runs it will fail statistically more often than if I don't touch the PC.

You can see in my original code that my PC app has a high-priority thread dedicated to reading video from the CX3.  Even so, running on Windows 10 on a i9-7920X CPU, there are momentary pauses when the system blocks data collection.  My point is the PC app is issuing IN tokens as fast as it can.  I do not know how to, or believe it is possible for the PC app to be more responsive to retrieving the CX3's video.

I did some early experiments that add a single 1 ms delay after exactly 359 buffers are collected to evaluate how tolerant the system is to multi-tasking delays.  I found that even a one 1 ms delay is enough to generate error 31 (0x1F).  For reasons I don't understand, once one of these errors occurs, the system cannot recover without reloading the CX3 firmware.  Simply restarting the PC app doesn't recover.

What questions do you have from my previous posts?

I appreciate your help,

Scott

0 Likes

Hi Scott,

Which host application are you using to stream the video data.

Also mention, Is the device binds to Cypress driver or UVC driver, check in device manager. If it is binding to Cypress driver test the speed of the device in Streamer application.

Thanks & Regards
Abhinav

0 Likes

Hi Abhinav,

I am using a simple OpenCV application I wrote using Visual Studio (in C) that interfaces using the Cypress driver.  The device doesn't transfer any data using the Cypress Streamer app, it just time's out.  I've tried all the packet sizes and transfer queue sizes, none work, however my application does indeed transfer and render video, for a few seconds, sometimes tens of seconds, until error 31 (0x1F) pops up.

Best,

Scott

0 Likes

Scott,

Is this issue (31 error) solved?

0 Likes

Scott,

Is the same issue re-producable in different Windows 10 PC?

Regards,

Sridhar

0 Likes

Hi Sridhar,

Yes.  We just tried our hardware on a second Win 10 PC.  It behaves nearly identically to my development PC.  There are still frequent error 31s running the sensor at 5Mp (full resolution).  Error 31 is pretty much non-existent at resolutions other than 5Mp, namely 1080p, 720p and 960p.

Scott

0 Likes

Hello Scott,

I understood that you are streaming the RAW 10 video data. It can be done using the UVC class drivers instead of Vendor class drivers.

In the case of UVC class, the device can mimic the host as UVC class device and send the RAW10 format data.

Here, you need to customize the UVC host application to stream the RAW10 video data.

You may refer to this. This can be applied to FX3 as well.

Streaming RAW10 Format Input Data to 16/24-bit Output Format in CX3 MIPI CSI-2 - KBA224387

I understood that the 31 error triggers when you stream 5MP and the video resolutions are streaming fine with 995 errors. Yes. performing extra operations during image transfer makes this error statistically more likely.

Regards,

Sridhar

Hi Sridhar,

We still frequently encounter error 0x31 that shuts down   imaging.  It

only happens when imaging at full sensor resolution,   5Mp.  We don't see

it at lower resolutions.

The more common error 995(decimal) is common at all   resolutions. It

seems performing any extra operations during image transfer   makes this

error statistically more likely.

So the direct answer to you question is no, these errors   still plague us.

Best,

Scott

0 Likes

Hello Scott,

You may use open source UVC host application https://mpc-hc.org/​  and do the necessary changes to display RAW10 video data.

Regards,

Sridhar

0 Likes