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

USB superspeed peripherals Forum Discussions

star_4282566
Level 1
Level 1
First like given Welcome!

Gents,

I am currently observing a curious behavior on a CX3 platform I have developed.
When users are trying to output frames with the following format 562x682xRAW8, frame size reported by the firmware (by summing DMA buffers size) is 384648 bytes which corresponds to a 564x682xRAW8 frame.
After some debug sessions it appears that, to work properly, line size has to be a multiple of 4 bytes otherwise some extra bytes are added at the end of each line.

As GPIF bus size is set to 16bits I was expecting line size to be a multiple of 2 bytes.

Is it a limitation of MIPI CSI-2 controller which has internal 32bit FIFO ?

Thanks for your support,

Stéphane

0 Likes
1 Solution
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Stephane,

We performed few tests internally. Based on that we can say that, the line size has to be multiple of 4 bytes. If not, then the extra padding occurs for the line data.

Regards,

Hemanth

Hemanth

View solution in original post

10 Replies
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Stephane,

Did you make sure that exactly 562 bytes are going for one line? And that there's no extra embedded data sent for each line.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

Yes, using another CSI capture platform I am getting correct data. In addition I observe the same behavior with two different sensors.

If you want to reproduce the issue, I am using the following mode to pack 2 RAW8 pixels on 16bits GPIF bus :

CY_U3P_CSI_DF_YUV422_8_2 = 0x26,    /**< YUV422 8-Bit Data type. CSI-2 Type 0x1E. \n

                                            24 Bit Output = 8'b0,P[15:0] \n

                                            16 Bit Output = P[15:0] \n

                                            Data Order: {Y1,U1},{Y2,V1},{Y3,U3},{Y4,V3}....  */

Best regards,

Stéphane

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Stephane,

Can you please post the snapshot of cx3 config tool here?

Regards,

Hemanth

Hemanth
0 Likes

Hi Hermanth,

Unfortunately not because I am not using it, I found it impractical to use and it is not working properly working on systems with french settings.

Anyway I have seen something interesting in cyumipicsi.c in CyU3PMipicsiSetIntfParams function :

1-First hResolution is rounded to a multiple of 8

/* Round up if hResolution is not multiple of 8 */

    if( (csiCfg->hResolution & CY_U3P_MIPICSI_HRES_MIN) > 0)

    {

        if(csiCfg->hResolution > CY_U3P_MIPICSI_HRES_MAX)

            csiCfg->hResolution = CY_U3P_MIPICSI_HRES_MAX; /* Round Down if crosssing max Value*/

        else

            csiCfg->hResolution = (csiCfg->hResolution & CY_U3P_MIPICSI_HRES_MAX) + 8; /* Round Up*/

    }

2-When setting mode to CY_U3P_CSI_DF_YUV422_8_2 wordcount is computed like this:

wordCount = (csiCfg->hResolution * 16)/8;

so in my case horizontal resolution is 562 ==> wordcount = 1080 !

What is the way to get the correct wordcount in CyU3PMipicsiSetIntfParams when packing 8bit pixels on 16bit bus

Regards,

Stéphane

0 Likes

Just a small update:

When horizontal resolution is 562 ==> wordcount = 1136 ((560+8)*16/8)

0 Likes

Hi Hemanth,

Here is the configuration I am using ... can you tell me where I am wrong ?

pastedImage_0.png

Best regards,

Stéphane

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Stephane,

Please use below configuration and let us know if you see data corresponding to 564*682? (instead of 562*682)

pastedImage_0.png

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

I have tried your settings and the behavior is exactly the same :

384648 bytes instead of 383,284 for 562x682xRAW8 frames ... 2 extra bytes per line giving a picture like this

pastedImage_1.png

Do you think the problem could be linked to UYVY mode ( used to pack bytes on 16bit bus) expecting 4 bytes to perform data processing ?

Regards,

Stéphane

0 Likes

Is it possible to have a definitive answer to this question ?

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Stephane,

We performed few tests internally. Based on that we can say that, the line size has to be multiple of 4 bytes. If not, then the extra padding occurs for the line data.

Regards,

Hemanth

Hemanth