cx3 clocks

[EtWh_2921621]

Not impressed with the developer community as a solution for questions AT ALL.  I have another question up here, for days, no reply by anybody.

Here's a simpler question, it's about clocks. First off, cypress' CX3 documentation on how to get an image sensor working is scattered, scant, and terrible. I'm surprised the CX3 is still a thing, with how bad the documentation is. That said, I doubt anybody is going to help me further. But let's try, maybe it will help other people.

The CX3 has an incoming system clock, it's 19.2 Mhz. Internally, it seems like this is multiplied by 20 to get SYS_CLK. Later in the docs, it states that the MIPI receive bus runs on a different clock, from the incoming REFCLK. In my case, that is 24MHZ. In the call to CyU3PDeviceInit, I pass in a CyU3PSysClockConfig_t, which has a flag in it, "setSysClk400", which tells the sys clock to run at a multiple of 21 instead of 20x the base incoming 19.2Mhz signal. But changing this value back and forth causes my captured frame rate to be different. This surprised me. Unless I am doing something very wrong, I figured the frame rate would stay the same, because it's being "latched" (for lack of a better word) from the MIPI bus, whose frequency is NOT changing based on setSysClk400. Anybody have an idea of why my FPS is changing?

Another thing I don't understand, since I inherited this firmware and hardware board, is LV and FV. My circuit doesn't have LV and FV coming in off GPIO lines from the sensor. How does the CX3 know when it's reached the end of a line or frame? I know it's happening, since it's capturing, but HOW is it working? I see no explanation for this anywhere.

Another thing I want to know is: We're using the OV4688(or 4689). It has been set up to output RAW8, but my cx3config.cycx is set up for input video format = RAW10, which I think is a mistake... Plus the GPIF bus has been set up for 24 bit. I don't understand the GPIF bus width, or why it should be one size or the other. Why not 32-bit? Is this just the size of the data that goes across the GPIO bus? or is it the transfer size (somehow) of what gets passed across the MIPI pixel data bus? Back to the Bayer thing: If I output RAW8 from the sensor, I'm assuming i choose input video format = RAW8. WHY oh WHY is there an "output video format"? The CX3 can't do format translation, so why is this box even there? Why can I choose 8, 16, or 24 bit? I don't get it. And if I choose one of those formats, what does that affect and which other registers do I need to set?

thanks from a very confused person.

[YashwantK_46]

Hello,

First of, the following thread which was created by you has been already answered in the link: CX3 vs Image Sensor PLL's - what's up?

Please take a look at the above thread.

"Later in the docs, it states that the MIPI receive bus runs on a different clock, from the incoming REFCLK."

=> The REFCLK for the CX3 is supplied by an external clock source which is used to power the MIPI bridge and in the CX3 Denebola RDK, both the REFCLK and CLKIN are being supplied with the same 19.2MHz clock source using a buffer in between to provide the same frequency to both the pins.

"Anybody have an idea of why my FPS is changing?"

=> Can you please let me what is the change in FPS being observed by you when you are changing the setSysClk400 parameter?

"I know it's happening, since it's capturing, but HOW is it working? I see no explanation for this anywhere"

=> Please refer to Section 1.9, Page 14 of the CX3_TRM.pdf (after installing the FX3 SDK) from the installation path: C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\doc\firmware

The above section of the document mentions about the fixed function GPIF II state machine in CX3 that works and samples data from the MIPI bridge.

Please read through the document to understand in depth about the technical aspects of the CX3 firmware and hardware implementation.

"We're using the OV4688(or 4689). It has been set up to output RAW8, but my cx3config.cycx is set up for input video format = RAW10, which I think is a mistake... Plus the GPIF bus has been set up for 24 bit. I don't understand the GPIF bus width, or why it should be one size or the other."

=> Refer to Section 1.6, Page 9-10 of the above mentioned CX3_TRM.pdf to understand better about the GPIF bus width and the video stream formats.

The Input Video Format needs to be set according to the format set in the image sensor while the Output Video Format which is used to select the GPIF bus width.

If you are streaming RAW10 and using 16-bit bus width, the higher bits are padded while if 24-bit is being used, more than one pixel is packed together into a frame and then sent to the host.

"Why not 32-bit? Is this just the size of the data that goes across the GPIO bus?"

=> Refer to section 1.5 of the above mentioned CX3_TRM.pdf which explains about the MIPI CSI-2 Block of CX3 and the configurable bus width available.

Please share your CX3 Configuration Utility's Screenshot so that i can review it on my end.

Regards,

Yashwant

[EtWh_2921621]

[EtWh_2921621]

Yeah... the vblank pixels are really small, but this shouldn't keep the CX3 from recognizing the image. The output pixel clock is at it supposed max of 100Mhz. With this configuration, the CX3 is seemingly capturing frames, but the PC is not receiving anything. If I boost the clock multiplier to 112, the PC starts to get frames. It's very odd... The reference clock IS 24Mhz.

I don't understand what PHY Time Delay Value actually does. If the value is smaller than it should be, what happens? Likewise, when it's larger than it should be, what happens? Similar questions for the FIFO delay. Will the image just look screwy, or will it simply not capture.

As I said, I'm printing out on the UART the average received frame rate... I'm getting ~90FPS. But the PC won't receive anything until MultiplierOfUnitClk is 112!

[YashwantK_46 · Accepted solution]

Hello,

The thread is branched to another thread: Re: Frames received by CX3, but not sent to PC. Why?

In response 2 of the above thread, the customer confirmed issue with the REFCLK value as follows:

"The project I took over had the wrong REFCLK for the CX3 input. It was shown as "24" when it was really "19.2". I was not clocking the CX3 fast enough"

Regards,

Yashwant