GC2385 CX3_ UVC USB 2.0 problem

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.
Anonymous
Not applicable

I want to use gc2385 via USB2.0, 800x600@15fps raw10 format. Now it can work in USB3.0 normally, but black screen in USB2.0. What is the highest resolution supported over USB 2.0?

pastedImage_2.png

pastedImage_1.png

I catched the data package, found the data size of first frame is much bigger than normal data. I am confused why it is normal over USB3.0.

abnormal: 36816x36+2812 = 1328188   

normal:  800x600x2 = 960000

pastedImage_3.png

0 Likes
1 Solution

Hi Michael,

Are you using status control EP in your application? These small packets (91) might be the status interrupt EP data.

First try  to decrease the output pixel clock to 25 MHz(approx) by adjusting PLL dividers and multipliers and check whether you are getting any CB failure in the debug logs.

Then you can try to increase the H blanking time also for USB 2.0. Also probe the H sync line and measure H blanking and H Active time so that we can calculate actual BW.

Thanks & Regards
Abhinav

View solution in original post

0 Likes
8 Replies
abhinavg_21
Moderator
Moderator
Moderator
50 likes received 25 likes received 10 likes received

Hi,

Please mention whether you are using same MIPI config in USB 3.0 and USB 2.0 mode? If you had made any modifications kindly mention.

What is the GPIF Bus width that you are using? I suggest you to manually change "CY_U3P_CSI_DF_RAW10"  to "CY_U3P_CSI_DF_YUV422_8_2" in "cyu3mipicsi.c" file to make use of 16 bit GPIF bus.

I observe that one packet size is 36855 but in the abnormal calculation you took 36816. Kindly explain?

What about the packet size after 1st frame? Is it according to the calculation?

Thanks & Regards
Abhinav Garg

0 Likes
Anonymous
Not applicable

HI,

     thanks for your feedback.

     1. I use same MIPI config in USB3.0 and USB2.0;

     2. I set the GPIF bus as 16 bit  in cycx3_uvc.h;

pastedImage_1.png

     3. The total package size is 36855, but the real size of mipi data is 36828, remove the package header(12BYTE), it is 36816.

          And after the first frame, the size of 1 frame is a little smaller than before, but still not correct.

0 Likes

Hi,

UVC driver doesnot support RAW data streaming. What are you getting on the e-cam application when you stream data using USB 3.0?

Please note that you have to manually change "CY_U3P_CSI_DF_RAW10"  to "CY_U3P_CSI_DF_YUV422_8_2" in "cyu3mipicsi.c" file.

Have you done it?

Please probe HSYNC & VSYNC lines in case of USB 2.0 and compare it with that of USB 3.0.

In the USB 3.0 working code, just search for "CyU3PConnectState (CyTrue, CyTrue);" API and make 2nd argument as CyFalse. This will disable the SS connection in the USB phy.

There is a possibility that HS descriptors are not defined correctly. Please refer the "CyCx3UVC_dscr" file present in the cycx3_uvc_ov5640 FW example code and change accordingly. I tried USB 2.0 with this FW only after disabling SS phy and I am able to stream 640X480 @60FPS.

Thanks & Regards
Abhinav

0 Likes
Anonymous
Not applicable

Hi,

          1. I used e-CAMView, it is normal over USB3.0.

          2. I think it is unnecessary to change "CY_U3P_CSI_DF_RAW10"  to "CY_U3P_CSI_DF_YUV422_8_2". Because it is all 16bit, and it works well over USB3.0.

          3. I try to set CyFalse in CyU3PConnectState (CyTrue, CyTrue), it is useless.

0 Likes

Hi,

Have you changed the probe control settings for HS according to the video format that you are streaming?

-- I try to set CyFalse in CyU3PConnectState (CyTrue, CyTrue), it is useless.

Are you able to stream video after disabling SS phy interface?

From traces I observe that there is some abnormality happening inside the firmware during 34th & 35th packet transfer, as there is a huge time difference in between. Could you please take the debug prints and attach it on the thread.

Thanks & Regards
Abhinav

0 Likes
Anonymous
Not applicable

Hi,

     After disable, it can't work over USB3.0 . But it is also abnormal in USB2.0. Beow is the package ia catched with USB2.0, very small.

pastedImage_4.png

     Thanks for your reminder, it is certain some abnormality between frame 34 and 35. I catch the package and log again,like attachment.

pastedImage_3.png

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

USB2.0 log

0 Likes

Hi Michael,

Are you using status control EP in your application? These small packets (91) might be the status interrupt EP data.

First try  to decrease the output pixel clock to 25 MHz(approx) by adjusting PLL dividers and multipliers and check whether you are getting any CB failure in the debug logs.

Then you can try to increase the H blanking time also for USB 2.0. Also probe the H sync line and measure H blanking and H Active time so that we can calculate actual BW.

Thanks & Regards
Abhinav

0 Likes