CX3 interfacing with Fixed MIPI Clock Speed

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

Hi, I have a sensor which can only support a fixed MIPI data rate of 891Mbps (which I assume means I enter 445.5MHz into the "CSI Clock" field).

It is a 4K sensor, and we are running it at a low enough framerate that the CX3 can theoretically support. We're trying to use 24-bit video-packing of the 12-bit RAW12 output.

However, there is no combination of settings that the configuration tool accepts.

The first problem is the acceptable "CSI Clock". At 20fps, the tool rejects the frequency as too low, though the minimum (777MHz) would break the CX3 per-lane data rate limit of 1Gbps?

The second problem is the output pixel clock is not accepted. It seems like the tool determines that the minimum pixel clock required is more than 100 MHz. However, at 3864x2180@20fps on 12bpp, and packing the pixels into 24-bit video format, we're looking at approximately 85MHz pixel clock rate, so why is there an error?

Thinking this might still work, I've generated the relevant files and ran it on the hardware. The following error appears upon wakeup:

GpifCB:WrapUp SCK0 Err = 0x47

Is there any documentation about the proper meaning of each field in the configuration tool and how they are derived?

0 Likes
1 Solution

Please use the following snippet in your code. This should be used in Main function. This may help you in solving 0x47 error.

    CyU3PSysClockConfig_t clkCfg;

        /* setSysClk400 clock configurations */

        clkCfg.setSysClk400 = CyTrue;   /* FX3 device's master clock is set to a frequency > 400 MHz */

        clkCfg.cpuClkDiv = 2;           /* CPU clock divider */

        clkCfg.dmaClkDiv = 2;           /* DMA clock divider */

        clkCfg.mmioClkDiv = 2;          /* MMIO clock divider */

        clkCfg.useStandbyClk = CyFalse; /* device has no 32KHz clock supplied */

        clkCfg.clkSrc = CY_U3P_SYS_CLK; /* Clock source for a peripheral block  */

    /* Initialize the device */

    status = CyU3PDeviceInit (&clkCfg);

    if (status != CY_U3P_SUCCESS)

    {

        goto handle_fatal_error;

    }

The CSI clock to 445.5 Mhz violates the FIFO delay limitation. You must not use this value.

Can you please check with Sensor manufacturer about custom CSI clock setting in the sensor?CX3

Please refer CX3 trouble shooting attached in this thread: Re: CX3 RDK board with OV7251 streaming problem

Also refer Question 2 in thread KBA regarding MCLK : CX3 Hardware: Frequently Asked Questions - KBA91295

i.e.

Question: Can CX3 provide a “Clock out” which can be used as a “Clock input” for an image sensor or image signal processor?

Answer: CX3 provides a clock output signal “MCLK” only for testing the image sensor. This signal is not suitable to use in final product. For production, use an external clock generator as clock input for image sensors.

View solution in original post

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

Seems like the Wrap Up error occurs only with the 24-bit output mode. If I switch to 16-bit output and lower the framerate to 10fps, streaming into the CX3 seems to occur, but the screen remains black. I can see from the application that no frames are received on the computer.

Turning on all the debugging messages, I can confirm that I'm getting all zeros for error counts. It I change CyU3PMipicsiSetPhyTimeDelay() around, errors start to occur, except for within the range of 0x05 and 0x10. So I've picked 0x0B as the middle point.

Prod = 173 Cons = 173  Prtl_Sz = 33440 Frm_Cnt = 15221 Frm_Sz = 6402608 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 32624 Frm_Cnt = 15222 Frm_Sz = 6401792 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 33232 Frm_Cnt = 15223 Frm_Sz = 6402400 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 33232 Frm_Cnt = 15224 Frm_Sz = 6402400 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 32944 Frm_Cnt = 15225 Frm_Sz = 6402112 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 33440 Frm_Cnt = 15226 Frm_Sz = 6402608 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 33440 Frm_Cnt = 15227 Frm_Sz = 6402608 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 33168 Frm_Cnt = 15228 Frm_Sz = 6402336 B

0 0 0 0 0 0 0 0 0

Prod = 173 Cons = 173  Prtl_Sz = 28448 Frm_Cnt = 15229 Frm_Sz = 6397616 B

0 0 0 0 0 0 0 0 0

The MIPI clock is continuous, and I've added a CyU3PMipicsiSetIntfParams() before sensor startup.

Probing PCLK, HSYNC and VSYNC... PCLK seems correct and produces a ~99 MHz clock as expected based on the clock and PLL setup. VSYNC is toggling at 10Hz, so that seems correct too.

HSYNC however doesn't seem to be toggling. It rises soon after VSYNC rises, but doesn't toggle as expected, and seems to be quite noisy. (See attached image, ignore the cursors) !

The received frame size also seems to be incorrect, at 3864x2180x12bpp, we are looking at about twice the number of bytes received per frame.

0 Likes
Anonymous
Not applicable

I figured there was not enough time for the MIPI receiver to consume each frame line, so after increasing the horizontal blanking, the CSI receive part seems to be working fine:

Prod = 462 Cons = 461  Prtl_Sz = 336 Frm_Cnt = 4837 Frm_Sz = 17009328 B

0 0 0 0 0 0 0 0 0

Prod = 462 Cons = 461  Prtl_Sz = 336 Frm_Cnt = 4838 Frm_Sz = 17009328 B

0 0 0 0 0 0 0 0 0

Prod = 462 Cons = 461  Prtl_Sz = 336 Frm_Cnt = 4839 Frm_Sz = 17009328 B

0 0 0 0 0 0 0 0 0

Prod = 462 Cons = 461  Prtl_Sz = 336 Frm_Cnt = 4840 Frm_Sz = 17009328 B

0 0 0 0 0 0 0 0 0

Prod = 462 Cons = 461  Prtl_Sz = 336 Frm_Cnt = 4841 Frm_Sz = 17009328 B

0 0 0 0 0 0 0 0 0

Prod = 462 Cons = 461  Prtl_Sz = 336 Frm_Cnt = 4842 Frm_Sz = 17009328 B

0 0 0 0 0 0 0 0 0

Received frame size is consistently 17009328, and the HSYNC signal seems correct now.

However, viewer is still showing a black screen. I've tried the Windows Camera App, VLC and our own application. All of them report no frames being received.

0 Likes
Anonymous
Not applicable

Anyone? Without support from Cypress I'm stuck here. It seems like I should get 24-bit output working, since apparently at 16-bit there is insufficient FIFO delay (maximum delay is negative).

However, with 24-bit output, I'm always getting the SCK0/SCK1 0x47 error. With only the term "CY_U3P_ERROR_INVALID_SEQUENCE" to go on, there's not much I can find.

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

Going back to 16-bit output. I see that frames are being sent to the computer. Capturing USB data with USBPcap, I can extract frames, but there is always a vertical band of corrupted pixels near the middle (see attached). Where is this coming from? I see that there is no way to meet the FIFO delay constraint, which is probably the reason.

However, I can't get frames to arrive at the computer in 24-bit mode. Can anyone tell me how to overcome the SCK 0x47 error? It seems like the only way forward.

0 Likes
Anonymous
Not applicable

Over one week and no response from the staff, while I see almost every other thread getting replies within 2 to 3 days. We've even emailed tech support and no responses. How do I even create a tech support ticket? The salesforce page only allows creating tickets for shipment or FA issues.

At this point, we are considering abandoning using the CX3 in our product.

0 Likes

Please set the Image Sensor to the following parameters:

1. CSI clock = 300 Mhz (Reduced)

2. Data Lane = 4

3. THS Prepare =  70.70707

4. THS Zero = 124

5. Frame Rate = 20 fps

6.  H Active = 3864

7. H Blanking = 520    

8. V Active = 2180

9. V Blanking = 40 (Reduced)

10. Data Format = RAW 12

Here is the MIPI configuration for the above image sensor parameters:

Output data format is 24-bit. Input 12 bit will be packed into the 24- bit parallel output format.

CyU3PMipicsiCfg_t null_RAW12_Resolution0 = 

{

    CY_U3P_CSI_DF_RGB888,  /* CyU3PMipicsiDataFormat_t dataFormat */

    4,                          /* uint8_t numDataLanes */

    2, /* uint8_t pllPrd */

    119 , /* uint16_t pllFbd */

    CY_U3P_CSI_PLL_FRS_250_500M, /* CyU3PMipicsiPllClkFrs_t pllFrs */ 

    CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t csiRxClkDiv */

    CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t parClkDiv */

    0,                 /* uint16_t mClkCtl */

    CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t mClkRefDiv */

    3864,         /* uint16_t hResolution */

    0                        /* uint16_t fifoDelay */

};

Set the THS Settle of MIPI receiver using CyU3PMipicsiSetPhyTimeDelay as 12 (pass this in the second argument).

Once you are done with the above, check whether there are any MIPI errors.

Note that you have to use the following procedure since the sensor is operating in continuous mode.

Refer question 13 in this KBA: CX3 Hardware: Frequently Asked Questions - KBA91295

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

Hi srdr,

  Thanks for the response. I'll try these out, but I have a few concerns:

1. Our sensor can only have a CSI clock of 445.5MHz (891Mbps lane), it cannot be changed. Would it be okay to set CSI clock to 300MHz?

2. Currently we have to clock the sensor from the MCLK out because our prototype is built that way, We need to generate a fixed 18 MHz output for the sensor. Hence our configuration looks like this:

CyU3PMipicsiCfg_t SEN_RAW12_4K10 =

{

CY_U3P_CSI_DF_RGB888,  /* CyU3PMipicsiDataFormat_t dataFormat */

    4,                          /* uint8_t numDataLanes */

    3, /* uint8_t pllPrd */

    164, /* uint16_t pllFbd */

    CY_U3P_CSI_PLL_FRS_500_1000M, /* CyU3PMipicsiPllClkFrs_t pllFrs */

    CY_U3P_CSI_PLL_CLK_DIV_8, /* CyU3PMipicsiPllClkDiv_t csiRxClkDiv */

    CY_U3P_CSI_PLL_CLK_DIV_8, /* CyU3PMipicsiPllClkDiv_t parClkDiv */

    0x0A0A,                /* uint16_t mClkCtl */

    CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t mClkRefDiv */

    3864,        /* uint16_t hResolution */

    0                        /* uint16_t fifoDelay */

};

I will try to match your configuration as much as possible, but is it okay if I use the above configuration instead (since Output clock is > 96 MHz of your configuration)?

3. Replicating your configuration in the configuration tool, I'm seeing it complain about the CSI clock being too slow. (See attached) I'll continue anyway

0 Likes
Anonymous
Not applicable

Hi srdr,

   Using your configuration, I'm getting mixed results.

    Windows Camera tries to start the camera but immediately closes it. eCAM opens the camera but does not stream, I see this in the serial output:

EnterSuspendMode Status =  0x0, Wakeup reason = 0x8

bRType = 0x1, bRequest = 0x3, wValue = 0x0, wIndex = 0x0, wLength= 0x0

StpCB:In SET_FTR 0::1

bRType = 0xA1, bRequest = 0x81, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0x21, bRequest = 0x1, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0xA1, bRequest = 0x81, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0xA1, bRequest = 0x83, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0xA1, bRequest = 0x82, wValue = 0x100, wIndex = 0x1, wLength= 0x22

    VLC opens and streams but I'm getting inconsistent output:

EnterSuspendMode Status =  0x0, Wakeup reason = 0x8

bRType = 0x1, bRequest = 0x3, wValue = 0x0, wIndex = 0x0, wLength= 0x0

StpCB:In SET_FTR 0::1

bRType = 0xA1, bRequest = 0x81, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0x21, bRequest = 0x1, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0xA1, bRequest = 0x81, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0xA1, bRequest = 0x83, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0xA1, bRequest = 0x82, wValue = 0x100, wIndex = 0x1, wLength= 0x22

bRType = 0x21, bRequest = 0x1, wValue = 0x200, wIndex = 0x1, wLength= 0x22

Configuring for 4K 20fps

AplnStrt:SMState = 0x2

Sensor Wakeup

Prod = 260 Cons = 259  Prtl_Sz = 10104 Frm_Cnt = 1 Frm_Sz = 9582264 B

0 1 0 0 0 1 0 0 1

Prod = 260 Cons = 259  Prtl_Sz = 10260 Frm_Cnt = 2 Frm_Sz = 9582420 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 10260 Frm_Cnt = 3 Frm_Sz = 9582420 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 11268 Frm_Cnt = 4 Frm_Sz = 9583428 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 10104 Frm_Cnt = 5 Frm_Sz = 9582264 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 10068 Frm_Cnt = 6 Frm_Sz = 9582228 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 10104 Frm_Cnt = 7 Frm_Sz = 9582264 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 10992 Frm_Cnt = 8 Frm_Sz = 9583152 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 10596 Frm_Cnt = 9 Frm_Sz = 9582756 B

0 0 0 0 0 0 0 0 0

Prod = 260 Cons = 259  Prtl_Sz = 10296 Frm_Cnt = 10 Frm_Sz = 9582456 B

0 0 0 0 0 0 0 0 0

However there is no output and VLC cannot shut down properly. I am trying to extract the raw USB packets instead.

0 Likes

Please use the following snippet in your code. This should be used in Main function. This may help you in solving 0x47 error.

    CyU3PSysClockConfig_t clkCfg;

        /* setSysClk400 clock configurations */

        clkCfg.setSysClk400 = CyTrue;   /* FX3 device's master clock is set to a frequency > 400 MHz */

        clkCfg.cpuClkDiv = 2;           /* CPU clock divider */

        clkCfg.dmaClkDiv = 2;           /* DMA clock divider */

        clkCfg.mmioClkDiv = 2;          /* MMIO clock divider */

        clkCfg.useStandbyClk = CyFalse; /* device has no 32KHz clock supplied */

        clkCfg.clkSrc = CY_U3P_SYS_CLK; /* Clock source for a peripheral block  */

    /* Initialize the device */

    status = CyU3PDeviceInit (&clkCfg);

    if (status != CY_U3P_SUCCESS)

    {

        goto handle_fatal_error;

    }

The CSI clock to 445.5 Mhz violates the FIFO delay limitation. You must not use this value.

Can you please check with Sensor manufacturer about custom CSI clock setting in the sensor?CX3

Please refer CX3 trouble shooting attached in this thread: Re: CX3 RDK board with OV7251 streaming problem

Also refer Question 2 in thread KBA regarding MCLK : CX3 Hardware: Frequently Asked Questions - KBA91295

i.e.

Question: Can CX3 provide a “Clock out” which can be used as a “Clock input” for an image sensor or image signal processor?

Answer: CX3 provides a clock output signal “MCLK” only for testing the image sensor. This signal is not suitable to use in final product. For production, use an external clock generator as clock input for image sensors.

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

Toggling the setSysClk400 to True indeed fixed the 0x47 error.

Regarding 445.5MHz violating the FIFO delay, the violation seems to go away if we change to 24-bit output, correct?

I'm still unable to get VLC, Amcap, Windows Camera and E-Cam to stream anything. However, capturing the raw USB data using wireshark, I am able to assemble the attached image. It is still incorrect, but seems to be an improvement as the noise bars are gone.

I understand the recommendation against using MCLK, but for the prototype we designed it to use MCLK first, hoping it is simpler. We will use an external oscillator eventually.

The current configuration is attached. We decided to go for 10FPS first. Also I will vary the blanking lengths after this post to see if things improve.

CyU3PMipicsiCfg_t SEN_RAW12_4K10 =

{

    CY_U3P_CSI_DF_RGB888,  /* CyU3PMipicsiDataFormat_t dataFormat */

    4,                          /* uint8_t numDataLanes */

    1, /* uint8_t pllPrd */

    81, /* uint16_t pllFbd */

    CY_U3P_CSI_PLL_FRS_250_500M, /* CyU3PMipicsiPllClkFrs_t pllFrs */

    CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t csiRxClkDiv */

    CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t parClkDiv */

    0x0405,                /* uint16_t mClkCtl */

    CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t mClkRefDiv */

    3864,        /* uint16_t hResolution */

    9                        /* uint16_t fifoDelay */

};

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

Hi,

Regarding the CX3CurrConfig10FPS.png attached above:

With the horizontal blanking value of 9324, 10 FPS can't be achieved.

Please change that to 4583 and test.

Also with the above configuration, set the THS Settle of MIPI receiver using CyU3PMipicsiSetPhyTimeDelay as 13 (pass this in the second argument).

Please let us know how the image looks after streaming starts?

Regards,

Hemanth.

Hemanth
0 Likes
Anonymous
Not applicable

Hi Hemanth,

   Changing to 4583 seems to have improved it somewhat. I also realise that due to switching to RGB888 mode for the MIPI receiver, for the raw data, we have to decode from the MIPI packing format, is that correct? If that is so, does the attached image look somewhat correct for a raw image direct from the MIPI receiver?

   Also, can you explain why is 4583 the number to test with? Is that the maximum H blanking allowed? I actually want to minimise the horizontal blanking, but the CX3 tool complains that it is too low. Also, with your suggested 4583, the tool complains that the blanking is too low as well.

   One more thing, why is it that the data is being streamed by USB but I cannot get any UVC applications to show the data on screen?

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

Image is attached. Can you suggest how the RGB12 sent using 24-bit packing will look like?

0 Likes
Anonymous
Not applicable

Okay, looking at the CSI-2 specifications, seems like the packing is correct, and we have managed to extract the correct image.

The remaining problems are:

1. What is the smallest H-blanking we can use?

2. Why is it that we cannot get any of the UVC apps to stream?

3. It seems that quite regularly, we get frame corruption (1 frame every 3 or 4 frames), is there something that can still be tuned?

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

Hi,

Regarding UVC Apps not streaming video:

- Can you let us know what format is being reported in the descriptor file?

If it is RAW format UVC Apps cannot display the image because UVC driver doesn't support the same.

Regards,

Hemanth

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

Hi hman,

Attached is my uvcdscr file, which is unedited from what the configurator gave.

It seems that UYVY is the reported format:

    /* GUID, globally unique identifier used to identify streaming-encoding format*/

    0X55,0X59,0X56,0X59,

0X00,0X00,0X10,0X00,

0X80,0X00,0X00,0XAA,

0X00,0X38,0X9B,0X71,

    0x0c,                              /* Number of bits per pixel: 12*/

    0x01,                              /* Optimum Frame Index for this stream: 1 (4K10) */

    0x00,                              /* X dimension of the picture aspect ratio; Non-interlaced */

    0x00,                              /* Y dimension of the pictuer aspect ratio: Non-interlaced */

    0x00,                              /* Interlace Flags: Progressive scanning, no interlace */

    0x00,                              /* duplication of the video stream restriction: 0 - no restriction */

    /* Class specific Uncompressed VS Frame Descriptor 1 - 4K10 */

    0x1E,                              /* Descriptor size */

    CX3_CS_INTRFC_DESCR,                /* Descriptor type*/

    0x05,                              /* Subtype:  frame interface*/

    0x01,                              /* Frame Descriptor Index: 1 */

    0x00,                              /* No Still image capture method supported */

    0x18,0x0f,                        /* Width in pixel:  3864 */

    0x84,0x08,                        /* Height in pixel: 2180 */

    0x00,0xed,0x3f,0x3c,            /* Min bit rate (bits/s): 3864 x 2180 x No Of Bits per Pixel x FrameRate = 1010822400 */

    0x00,0xed,0x3f,0x3c,            /* Max bit rate (bits/s): Fixed rate so same as Min */

    0x90,0xcc,0xc0,0x00,            /* Maximum video or still frame size in bytes(Deprecated): 3864 x 2180 x 2 */

    0x40,0x42,0x0f,0x00,            /* Default frame interval (in 100ns units): (1/30)x10^7 */

    0x01,                              /* Frame interval type : No of discrete intervals */

    0x40,0x42,0x0f,0x00,            /* Frame interval 3: Same as Default frame interval */

I believe that should at least show something on most UVC applications?

Debugging libuvc when using the capture application, it seems that dwClockFrequency is zero, which is what causes the application to fail. Is this a value reported by CX3?

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

Hi,

I had a look at your descriptor file. I noticed that the bits per pixel field in your Frame descriptor is mentioned as 12.

Since YUY2 format has two bytes per pixel, we can try the following:

1. Change your pixel height from 2180 to 1635

2. Change bits per pixel from 12 to 16.

Now the Host receives exactly 3864*1635*16*10 bits which is 1010822400 bits (same as present).

FYI:

1. UVC driver cannot handle raw data.

2. Now we have reported the video format as YUY2 and hence any standard video application which is based on UVC driver would display the image(but it will not be as you require)

3. So the way to handle it would be: modify the Host side application such that after you receive image data from the driver you need to convert it to displayable format.

As of now for 10 fps, if you change the pixel height and bits/pixel you can see some display on the player.

Let me know if you have any questions.

Regards,

Hemanth

Hemanth
0 Likes
Anonymous
Not applicable

Thank you very much! The biggest issue has been solved.

Now we need to figure out how to properly implement Controls. Both the AS0260 and OV5640 examples do not have any controls implemented. Is there an example of how to do so? From what I can see in the code generated by the CX3 configurator, we need to implement handling the request/response in CyCx3UvcApplnUSBSetupCB().

But it seems like some major changes are required as currently there is no logic to detect what the request is, and the code just responds with probe data. Roughly what do we need to change in the following to get, for example, brightness control to work?

                case CX3_USB_UVC_GET_CUR_REQ:

                case CX3_USB_UVC_GET_MIN_REQ:

                case CX3_USB_UVC_GET_MAX_REQ:

                case CX3_USB_UVC_GET_DEF_REQ:

                {

                    isHandled = CyTrue;

                }

                break;

                case CX3_USB_UVC_SET_CUR_REQ:

                    CyCX3ApplnHandleSetCurReq (wValue);

                    isHandled = CyTrue;

                break;

I've changed the uvcdscr accordingly to enable brightness control, but UVC initialisation fails as probing for the brightness max/min/def fails.

Anyways, I'll mark this thread as answered. Will open another thread if I still cannot figure out handling the control requests.

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

Hi,

Regarding the UVC controls: yes you can open a new thread.

But as a quick answer:

You can refer to app note AN75779 firmware(http://www.cypress.com/documentation/application-notes/an75779-how-implement-image-sensor-interface-... ), where processing unit controls are handled.

Please refer to the above firmware and you can create a new thread if you have any questions.

Regards,

Hemanth

Hemanth
0 Likes