cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

JeZy_4330396
New Contributor II

Hello Cypress Community,

i create a new topic because i cannot success to get the image. I am only getting half of the FPS, i m only receiving 7-8 fps, or it should be 15 fps... And I cannot figure it out, i checked the test point on the Cx3 Board (Pixel Clock, Line Valid and Frame Valid) and all seem to be good (Screen below).

Do you have an idea why ?

My configuration :

Image X: 1920

Image Y 1080

Format RGB 888 (24 bits)

15 Fps

Cx3 Configuration :

- Number of DMA : Set to 3 (but 6 in real because of the MANY-To-oNE mode if i well understand)

- Dma Size(include Header and footer) : 30720 bytes

- Header size : 12

- Footer Size : 372

- GPIF : 24 bit

1) Screen on a lane of the incoming Mipi :

tek00000.png

V-Total(us) = 66.6

V-Blanking(us) = 10.8

V-Blanking(Line) = 209

TEK00001.PNG

H-Total(us) = 50.4

H-Blanking(us) = 31.2

H-Blanking(pixel) = 2880

2) Pixel clock (test point Cx3) :

TEK00002.PNG

Clock  : 72 MHz

3) Frame Valid (VSYNC) (Cx3 test Point) :

tek00000.png

Period : 67.2 ms

4) Line Valid (HSYNC) (Cx3 Test Point)

TEK00001.PNG

Image Period 66 .4 ms

- Zoom  :

TEK00002.PNG

Line Period : 51.60 us

5) Mipi Configurator Tools

pastedImage_2.png

If you need more information tell me.

Thank you in advance,

JZ

0 Likes
1 Solution
Rashi_Vatsa
Moderator
Moderator

Hello Jeremy,

Both the sensor settings and the MIPI settings are set by the user.

The Cx3 Configuration tool doesn't do any major changes. It does a simple calculation based on the Inputs user gives to the utility. The calculation of the V Active  is done by the tool considering the H Total (resolution given to the tool) and the V Active ( as per input given to the tool) and similarly the V total is calculated.

V Active (time) = H -Total * V-active /1000 ms

V- Total(time) = H-Total * (V-active+V_blanking)/1000 ms

The input from the sensor is expected to come in similar manner. If the settings of the sensor is not in sync with the MIPI settings (input given to the tool (i.e. the left side of the Configuration utility MIPI CSi2 Inputs)). If both these things don't match, there are chances of the glitches/ misbehavior in the application.

According to your inputs the V blanking is calculated as 11 ms by the tool but the sensor is not giving the same.

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
15 Replies
Hemanth
Moderator
Moderator

Hi Jz,

Since your buffer size is 30720 and header + footer = 384 bytes, number of full DMA buffers needs for your frame is 1920*1080*3/(30720-384)

= 205 and a partial buffer. Please take a wireshark trace and check if every frame is constituted like this. (You should also verify in the trace that every frame has got 206th buffer/payload as partial buffer with same number of bytes every frame)

Can we know why you adding 372 bytes footer? Is the device UVC compliant?

Are you getting any commit buffer failures? (Please check UART prints)

Regards,

Hemanth

Hemanth
0 Likes
JeZy_4330396
New Contributor II

Hello Hemanth, thank you for your response.

No my device isn't UVC compliant because i have to use a custom app.

I'm using 372 bytes of footer for the dma to be a multiple of 24 and also multiple of burst packet(i hope this improve usb speed).

I have checked with wireshark, my packet seems correct(i added a header into each usb packet like in UVC example).

But i cannot figure out why there is only half of the fps, and i have no mipi error, and no Commit Buffer Failures....

Maybe my problem comes from DMA Size ? It is possible ? What is the recommanded DMA Size for GPIF 24 bits ?

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello Jeremy,

There is possibility of  a problem due to DMA Buffer size. Generally, the DMA buffer size should be a multiple Endpoint size which 16 KB in case of USB 3.0.

(Bulk EP : 1024 * 16 burst)

As mentioned in AN75779:

Setting DMA buffer size exactly equal to line size is also not a good solution because it does not take advantage of the USB 3.0 maximum burst rate for BULK transfers. USB 3.0 allows a maximum of 16 bursts of 1024 bytes over BULK Endpoints. This is why the DMA buffer size is set to 16 KB.

To confirm what exactly is happening at the USB interface, please share the USB traces. You can wire shark for that.

Regards,

Rashi

Regards,
Rashi
0 Likes
JeZy_4330396
New Contributor II

Hello Rashi,

So I try to set the dma to 16kb with 16 burst of 1024, but i have too many Commit Buffer Failure.

I succeded to get an image at 8 fps,(still half of the incoming mipi at 15 fps ), and no commit buffer failure, with this configuration :

FULL DMA SIZE : 30736

Header : 12

Footer : 4

Number DMA : 3

Burst Length : 10

Packet Size : 1024

See in attachment the USB trace with WireShark for the previous configuration.

I use a header in each usb frame as follow :

1st Byte: Header size (0x0C)

2nd Byte : Frame status (0x01 = Regular Frame, 0x10 = EOF)

3rd Byte : Frame counter

I think the problem is from the mipi block or gpif side, because usb works good..

Thank you,

JZ

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello Jeremy,

As you are getting Commit Buffer Failure when DMA buffer size is 16 KB and Endpoint size is 16 KB and when you are configuring DMA buffer size to 30736 and Endpoint size 10 *1024 the fps is half. There is possibility that the Host (host application) is slow enough to fetch the data from the DMA buffer.

Can you check the number of PROD events and CONS event in the DMA Callback function. You can get the waveform traces by toggling the GPIOs

Also, let me know the GPIF bus width and also the XferDatasize that host application is asking for.

Regards,

Rashi

Regards,
Rashi
0 Likes
JeZy_4330396
New Contributor II

Hello Rashi,

Yes but if the host is too slow to read usb packet in time, this causes DMa Commit Buffer Failure, but here it is not the case.

I have added counter to see prod event, cons event and number of partial dma (so end of frame), all of this counter are incremented into the DMa Callback.

Log from the cx3 uart :

(usb command) APP START

*** Update 1 secs ***

ResetCount : 0

Prod event : 0

Cons event : 0

Partial Buffer : 0

GPIF state : 2

*** Update 1 secs ***

ResetCount : 0

Prod event : 1062

Cons event : 1061

Partial Buffer : 5

GPIF state : 131

*** Update 1 secs ***

ResetCount : 0

Prod event : 2639

Cons event : 2639

Partial Buffer : 13

GPIF state : 16

*** Update 1 secs ***

ResetCount : 0

Prod event : 4116

Cons event : 4115

Partial Buffer : 20

GPIF state : 5

*** Update 1 secs ***

ResetCount : 0

Prod event : 5684

Cons event : 5684

Partial Buffer : 28

GPIF state : 1

ps: Reset Count is incremented if we got Dma Commit Buffer Failure

We can see that we have each second around 1500 prod/cons event, which correspond to 7-8 fps...

(1920 * 1080 * 3 / 30720 = 202.5 prod event for 1 frame, so for 8 fps is equal to 1620 prod event each second).

GPIF Bus width is 24 bits, and the host application is asking for 30736 bytes with XferData.

Thank you,

JZ

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello Jeremy,

Can you check streaming using the default firmware from the SDK with your sensor as well as your custom host application.

Please take the usb traces and share.

Regards,

Rashi

Regards,
Rashi
0 Likes
JeZy_4330396
New Contributor II

Hello Rashi,

No i cannot use default firmware, because i have added some feature in my firmware (like i2c command, and others things as host command), it will take too much time to adapt the default firmware to get the streaming with my system...

Do you think the problem can come from the gpif ? What can i test to confirm that ?

Thank you Rashi,

ZYGMUNT Jeremy

0 Likes
JeZy_4330396
New Contributor II

Hello, may be i have an idea.

I checked the Frame Valid signal signal, and with this camera at 15fps in rgb888, the frame valid signal goes down onlu 94.0 us :

tek00000.png

I checked on an other camera at 30 fps in raw8(working) and the frame valid goes down for 3.4 ms.

Is it possible that this delay is too short, and the gpif miss the frame Valid state Low ? And this is why i m getting only half of the fps ?

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello Jeremy,

It seems that this can be problem. As you said sensor settings are 15 fps so total Frame Valid period should be ~66.6 ms ( is also same in CX3 configuration Utility you shared). The CX3 configuration Utility snippet is configured for V active 55 ms + V Blanking (11 ms) = V Total (66.67ms)

So getting 90 us for V blanking instead of 11 ms can be a problem.

Regards,

Rashi

Regards,
Rashi
0 Likes
JeZy_4330396
New Contributor II

Hello,

Do you know why i'm not getting the same blanking ?

Is it possible to change this blanking output from the mipi block ?

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello Jeremy,

The blanking period can be set by setting appropriate registers in the camera sensor.

The Fifo delay can be adjusted to change the H blanking but not the V blanking. It would be preferable to change the V blanking by changing sensor settings.

Regards,

Rashi

Regards,
Rashi
0 Likes
JeZy_4330396
New Contributor II

Ok thank you Rashi, i will try that.

But I stil have a question

Why the mipi V-Blanking is 11 ms , and at the ouput of the mipi block with have a frame valid witth 99 us of blanking ?

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello Jeremy,

Both the sensor settings and the MIPI settings are set by the user.

The Cx3 Configuration tool doesn't do any major changes. It does a simple calculation based on the Inputs user gives to the utility. The calculation of the V Active  is done by the tool considering the H Total (resolution given to the tool) and the V Active ( as per input given to the tool) and similarly the V total is calculated.

V Active (time) = H -Total * V-active /1000 ms

V- Total(time) = H-Total * (V-active+V_blanking)/1000 ms

The input from the sensor is expected to come in similar manner. If the settings of the sensor is not in sync with the MIPI settings (input given to the tool (i.e. the left side of the Configuration utility MIPI CSi2 Inputs)). If both these things don't match, there are chances of the glitches/ misbehavior in the application.

According to your inputs the V blanking is calculated as 11 ms by the tool but the sensor is not giving the same.

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
JeZy_4330396
New Contributor II

Ok thank you Rashi for all your responses.

JZ

0 Likes