cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Way
Adventurer
Adventurer
1,193 Views
Registered: ‎10-19-2020

Why MIPI RX subsystem where clock lane always stay in low power mode

Hi, 

I am using the MIPI Rx Subsystem in Vivado 2020.1 with OV5640 camera sensor. I understand that Dphy need to see LP11 during initialization. Hence, I get the MIPI Rx subsystem to be initialized first then only initialize the camera sensor.

After that, I tried to dump out all the register regarding DPHY and CSIRX controller. I saw that the DPHY register CL_Status and DL_Status getting the Init_Done bit set to high. With this, I think the initialization is successful. However, while i continue sample the Dphy register, I saw that the CL_Status is always stay with 0x00000008 which mean the clock lane is always in low power mode. Whereas in DL_Status, the register value sampled is changing from 0x9 ->0x48 -> 0x9 ...etc. Hence, it seems like the data lane is entering HS and LP continuously. In CSIRX register, I did not see any packet is received by looking at packet count or frame received interrupt status.

Initially I am getting the MIPI Rx Subsystem line rate set to the maximum rate supported. After reading through some comment from the forum, it seems like it is better to set it to be the same as camera output rate. I had changed the line rate according to the camera output. The calculation is as below:

Using frame size with blanking consideration:

2844*1968*15fps*16bpp = 1343Mbps /2 (two lanes) = ~672Mbps (value that I set in linerate)

 

However, I am still seeing the same behavior whereby the CL_Status always stay with 0x8. I would like to ask if is there any suggestion/debug direction for me in this scenario?

Attached are dphy register value.

 

Tags (2)
dphy.PNG
0 Kudos
24 Replies
karnanl
Xilinx Employee
Xilinx Employee
1,139 Views
Registered: ‎03-30-2016

Hello @Way 

>Hence, I get the MIPI Rx subsystem to be initialized first then only initialize the camera sensor.
>After that, I tried to dump out all the register regarding DPHY and CSIRX controller. I saw that the DPHY register CL_Status and DL_Status getting the Init_Done bit set to high.

Thanks for the update. Congratulations.

>However, while i continue sample the Dphy register, I saw that the CL_Status is always stay with 0x00000008 which mean the clock lane is always in low power mode.
>Whereas in DL_Status, the register value sampled is changing from 0x9 ->0x48 -> 0x9 ...etc. Hence, it seems like the data lane is entering HS and LP continuously.
>In CSIRX register, I did not see any packet is received by looking at packet count or frame received interrupt status.

Noted.

>I would like to ask if is there any suggestion/debug direction for me in this scenario?

If I can remember correctly, you are using
   - 7-series device
   - Vivado 2020.1

1. Are you using external D-PHY IC ? or a resistor network (as mentioned in XAPP894 Compatible solution) ?
2. Could you please re-check Clock lane connectivity on your board ? is P/N connectivity swapped ?
3. What is the IO standard you are using for LP and HS pins ? (Please share the VCCO value too)
4. Do you have a simple block diagram of your system ? ( illustration of TX and RX and everything on its path )
5. Do you have any waveform capture from FPGA IO pins ?
    # You need to ensure that signal level at FPGA pins are within datasheet DC spec.
    # You also need to check if LP-->HS transition signal level is expected.

Kind regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
Way
Adventurer
Adventurer
1,121 Views
Registered: ‎10-19-2020

Hi @karnanl 

Ya, I am using 7 series devices with Vivado 2020.1.

1. I am using external DPHY IC (meticom  MC20901)

2. I rechecked the clock lane and the P/N connectivity is correct.

3. The IO Standard that I am using for LP is set to LVCMOS25 whereas HS pins is set to LVDS25 in Vivado. Both LP and HS are assigned to the same IO bank and VCCO for that particular bank is 3.3v. Is it ok? 

4. The simple block diagram is as attached

5. Currently I do not have waveform captured with oscilloscope from the FPGA IO pin, the hardware is with my colleague. I will try to do it .

simple_block_diagram.PNG
0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
1,108 Views
Registered: ‎03-30-2016

Hello @Way 

>1. I am using external DPHY IC (meticom MC20901)
>2. I rechecked the clock lane and the P/N connectivity is correct.
>4. The simple block diagram is as attached

Noted. Thank you for sharing this information.

>5. Currently I do not have waveform captured with oscilloscope from the FPGA IO pin, the hardware is with my colleague. I will try to do it .

Understand. Yes please share the captured waveform later.

>3. The IO Standard that I am using for LP is set to LVCMOS25 whereas HS pins is set to LVDS25 in Vivado. Both LP and HS are assigned to the same IO bank and VCCO for that particular bank is 3.3v. Is it ok?

Would you able to use VCCO=2.5V ? LVCMOS25 requires VCCO=2.5V.
For LVDS_25, Are you using external termination ? or internal differential termination ? (Please see also UG471 for more details info)

Kind regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
1,078 Views
Registered: ‎10-19-2020

Hi @karnanl 

Regarding the VCCO for the IO bank, I just checked the schematic again and the VCCO is 2.5v. Sorry for the wrong information previously. I went through the UG471 and the internal termination can be turned on when VCCO is the same as IO standard. The internal termination is off by default and hence may i know should I enable internal differential termination in this case since the VCCO is 2.5v? But looking at the data lane which located in the same IO bank with current setting, it seems to be ok.


Also, regarding the signal level at FPGA pins are within datasheet DC spec, do you mean the input voltage  VIL and VIH in LVCMOS25 in table 8 and Vindiff in LVDS_25 in table 11 as shown in the datasheet here? Is it have to make sure the input voltage from Meticom IC to FPGA IO pin is within the VIL/VIH in LVCMOS25 and Vindiff in LVDS_25?

karnanl
Xilinx Employee
Xilinx Employee
1,059 Views
Registered: ‎03-30-2016

Hello @Way 

>I just checked the schematic again and the VCCO is 2.5v

Okay, noted.

>The internal termination is off by default and hence may i know should I enable internal differential termination in this case since the VCCO is 2.5v?

LVDS needs 100ohm termination.
If your board does not implement it externally, please enable internal term by using "set_property DIFF_TERM TRUE [get_ports ..]"
See also : https://www.xilinx.com/support/answers/71582.html

>Is it have to make sure the input voltage from Meticom IC to FPGA IO pin is within the VIL/VIH in LVCMOS25 and Vindiff in LVDS_25?

Yes.
Are you able to check the FPGA input signal level on your HW ?

Kind regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
1,044 Views
Registered: ‎10-19-2020

Hi @karnanl ,

Ok, I will try to enable the DIFF_TERM on my design. Reading the AR#71582, it seems like the DIFF_TERM will be enabled by default for MIPI CSI-2 RX subsystem release after 2018.3?

About the hardware waveform, please see the attached file. I am not sure if the way I capture the signal is correct or not. Please let me know if it is not correct.

Looking at the waveform, it seems like the LVDS input is still within the spec which is less than maximum 600mv as mentioned in datasheet. Whereas the LVCMOS is almost hit the maximum value specified in datasheet with is Vcco + 0.3.

Beside, the HS_Clk is continuously running as shown in the waveform but I am not sure why the clock lane is still in low power mode as indicated in the register as well as no packet is received. I do not sure how to check whether the camera sensor start with LP11 first by using oscilloscope to capture the waveform since everything already started when start to capture the waveform. I think camera sensor should have started with LP11 since the INIT done signal is asserted in the register.

Please let me know if anymore information needed and really appreciate the help provided.

 

karnanl
Xilinx Employee
Xilinx Employee
1,019 Views
Registered: ‎03-30-2016

Hello @Way 

>it seems like the DIFF_TERM will be enabled by default for MIPI CSI-2 RX subsystem release after 2018.3?

This is for UltraScale+, not 7-series device.
MIPI CSI-2 RX IP for 7-series does not generate any IO constraint. You need to add constraint in XDC file.


BTW, I can see that you are using OV5640 sensor. I see a few other users who use OV5640 sensor without any issue.

>Beside, the HS_Clk is continuously running as shown in the waveform but I am not sure why the clock lane is
>still in low power mode as indicated in the register as well as no packet is received.

Perhaps, Clock lane is already toggling/sending HS clock, while MIPI CSI-2 is initialized ? Could you please confirm ?
Also could you please try to change sensor "Clock lane gate enable" configuration ?

Sensor_has_free_running_clock.png


Regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
1,003 Views
Registered: ‎10-19-2020

Hi @karnanl ,

I added the DIFF_TERM into the constraint file and it appear that the behavior is still the same where clock lane is still in low power mode. However, once I configured the OV5640 to enable the clock lane gate enable, it appear that the clock lane can go into HS mode. Hence, probably Clock lane is already toggling/sending HS clock, while MIPI CSI-2 is initialized.

In my initial software, I already purposely getting the MIPI CSI2 initialized first then only initialize the sensor and thought that this can prevent clock lane already toggling HS clock. I will be going to confirm it. I am thinking how to confirm whether clock lane already sending HS clock once started. Is it we can just start capture the HS clock once everything power up without running the sensor initialization code as to confirm clock lane sending HS clock once system get started?

 

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
965 Views
Registered: ‎03-30-2016

Hello @Way 

Noted. I agree with that.

Please ensure that OV5640 is actually sending LP-11 (or LP-00) when MIPI CSI-2 RX in reset.
Some sensor may actually outputs Hi-Z before sensor device initialization completes. (You may not able to differentiate LP-00 and Hi-Z easily using oscilloscope.)
So please double check with sensor vendor/distributor too.

Regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
958 Views
Registered: ‎10-19-2020

Hi @karnanl 

I captured the waveform and it appear that the clock lane has already sending the HS clock. Thank for suggestion and help provided on this.

Once I switch to clock gate mode, I notice that the DPHY clock lane status toggle between low power mode and HS mode. Also, the DPHY data lane packet count is increasing.

However, the CSIRX packet count in core status register is 0 which mean no packet is received on CSIRX. The interrupt status register is staying at 0x00020000 which indicate the stop state is high. Looking at clock lane info register, the value change from 0x0->0x2->0x0 whereas lane info register change from 0x0 -> 0x20 ->0x0. It appear that clock lane info and lane info register is ok. Wonder if do you have any suggestion on what is causing this behavior?

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
939 Views
Registered: ‎03-30-2016

Hello @Way 

>I notice that the DPHY clock lane status toggle between low power mode and HS mode. Also, the DPHY data lane packet count is increasing.

This seems to be an improvement, but we need to ensure that
  1. Initialize OV5640 sensor
  2. Confirm that MIPI CSI-2 RX is receiving LP-11 (or LP-00)
  3. Reset MIPI CSI-2 RX
  4. Trigger OV5640 sensor to send video data ( LP -> HS -> LP -> HS ...)

for both clock-lane and data-lane.

 

> Looking at clock lane info register, the value change from 0x0->0x2->0x0 whereas lane info register change from 0x0 -> 0x20 ->0x0.

It seems clock/data lane behave as expected.
CLOCK_DATA_LANE_behave_as_expected.png


>However, the CSIRX packet count in core status register is 0 which mean no packet is received on CSIRX

Perhaps INIT_DONE for MIPI D-PHY clock lane is not asserted ? Could you please confirm ?

Could you please share MIPI CSI-2 RX and MIPI D-PHY register dump ?

Regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
928 Views
Registered: ‎10-19-2020

Hi @karnanl 

I noticed that the MIPICsiRxSubsystem is using 4 active lanes while the sensor is only using 2 lanes. Hence, I change the active lane to 2 by writing to protocol configuration register. With this modification, now I am able to see the packet count increase in core status register. Initially, I thought it will be fine to have 4 active lanes in MIPI IP where sensor is using 2 lanes only. But, it seems like active lanes in sensor and MIPI IP need to be matched?

However, looking at the interrupt status, there are a lot of error indicated in the register such as SotErr, VCxFrameErr, EccErr and etc after CSIRx seems to be able to receive the packet.

Did a checking on the INIT_DONE for MIPI  D-PHY for both clock lane and data lane. Both are okay.

Wonder if what is the possible reason or something I am doing wrongly that causes so much error stated in Interrupt status register?

Attached is the register dump for DPHY and CSIRX core

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
906 Views
Registered: ‎03-30-2016


Hello @Way 

>But, it seems like active lanes in sensor and MIPI IP need to be matched?

Yes, that is correct.
If sensor is using 2 data lanes, MIPI CSI-2 has to be configured as 2 data lanes.

>Did a checking on the INIT_DONE for MIPI D-PHY for both clock lane and data lane. Both are okay.

Thank you. Noted.

>However, looking at the interrupt status, there are a lot of error indicated in the register such as SotErr, VCxFrameErr, EccErr and etc after CSIRx seems to be able to receive the packet.

I can see MIPI CSI-2 RX address 0x24 has a lot of errors. (value==0xc05a3daa). This is not good.

1. Did you set MIPI CSI-2 RX line-rate configuration in the GUI to match OV5640 sensor line-rate ?
2. Could you please clear ISR (address 0x24) value once, by writing "all 0xFFFF_FFFF", and read back 0x24 register ?
    Do you see the same value ?
3. Instead of generating MIPI CSI-2 RX as 4-lane, could you please generate as 2-lane and test it on your HW ?


Regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
865 Views
Registered: ‎10-19-2020

Hi @karnanl 

1. I have been looking for some information about sensor output rate but couldn't find exact information on which register value I should use to calculate it. Looking at the OV5640 register 0x380C/D/E/F setting for total horizontal size and total vertical size which 2844*1968. The sensor datasheet didn't well mentioned on these register and so I not really sure whether is this register represent the total frame size with blanking, but i guess it should be. Then with 15fps and 16 bpp. Since the sensor is operating with 2 lane, I divided the bandwidth by 2. Please let me know if my current calculation is not correct.

2844*1968*15fps*16bpp = 1343Mbps /2 (two lanes) = ~672Mbps (value that I set in linerate)

 

2. By clearing the interrupt status register, it seems like I am not seeing the same error bit happen anymore. But, I do not understand why this is happening. Wonder if do you have any comment on this?

- One thing is I also clear the VCX Frame Error Register 0x34 because I noticed that the interrupt status register will also assert VCxFrameError signal (bit 30) after clearing the interrupt status register. I think it should be due to previous error asserted in register 0x34. After I clear VCX Frame Error Register 0x34 and interrupt status register 0x24, it appear that I no longer see any error in Interrupt status register.

3. I tried to setup the 2 lane configuration and change the linerate to be higher ~900Mbps. It seems like there is no any differences where the interrupt status register will still be having a lot of error and we need to clear it.

Attached is the register dump after clearing the VCxFrameError register and Interrupt status register. It seems like now the register value is good. 

0 Kudos
karnanl
Xilinx Employee
Xilinx Employee
853 Views
Registered: ‎03-30-2016

Hello @Way 


>1. I have been looking for some information about sensor output rate but couldn't find exact information on which register value I should use to calculate it. Looking at the OV5640 register 0x380C/D/E/F setting for total horizontal size and total vertical size which 2844*1968. The sensor datasheet didn't well mentioned on these register and so I not really sure whether is this register represent the total frame size with blanking, but i guess it should be. Then with 15fps and 16 bpp. Since the sensor is operating with 2 lane, I divided the bandwidth by 2. Please let me know if my current calculation is not correct.
>- 2844*1968*15fps*16bpp = 1343Mbps /2 (two lanes) = ~672Mbps (value that I set in linerate)

672Mbps is the actual data-rate. Sensor MIPI line-rate outputs should be faster than the actual data-rate.

Looking at OV5640 datasheet, I believe your sensor is sending 96MHzx8=768 Mbps line-rate@2lane.
Please confirm this with your sensor distributor too.
OV5640_has_768Mbps_linerate.png

>2. By clearing the interrupt status register, it seems like I am not seeing the same error bit happen anymore.
>But, I do not understand why this is happening. Wonder if do you have any comment on this?

I am not sure why but If this is the case, I believe error occurs after initialization process. So after clearing the ISR
If you no longer see error register asserted, I believe MIPI CSI-2 RX is working without any issue.
# Please note that the following bits are not error registers.
    Bit[31] = Frame Received
    Bit[17] = "Stop-state"

Kind regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
797 Views
Registered: ‎10-19-2020

Hi @karnanl 

Thanks for the details about the MIPI linerate.

Noted that FrameReceived and Stop-State is not the error bit.

One thing I noticed was when I clear the interrupt register differently as what I did previously, it appear that Short packet FIFO full bit 20 is still remained in the interrupt status register. In my previous test, I start to clear the interrupt status register after perform read twice to all the csirx register. From the value sampled on CoreStatusRegister, it appear that the Short Packet FIFO full bit is asserted (1) at first sample value and change to de-asserted (0) at second sample value. So coincidently, my clear interrupt status register command happened after second sample value which manage to get interrupt status register set to 0 for ShortPacketFIFO bit 20.

Today, I started to clear the interrupt status register just after the camera sensor initialization without reading back twice all the csirx register (because thought thing are working fine already). It appear that the ShortPacketFIFO full bit is asserted in CoreStatusRegister as well as interrupt status register's ShortPacketFIFO bit 20. Reading to the CoreStatusRegister, it also show ShortPacketFIFO full bit is asserted. However, both previous test or current flow actually are having same initialization/flow before clear interrupt status register except reading twice to all csirx reg in previous test and now without reading twice to csirx reg. I am running out of idea what is causing this behaviour.

Hence, I would like to ask

1. Do you have any comment on what might causing this weird behavior?

2. Do you have any suggestion on when will be a good time to do the clear interrupt status register in this case?

3. Also, just would like to understand about the short packet, Is this short packet also get clocking out with video_aclk just like pixel data? And the ShortPacketFifo full is due to video_aclk too slow or any other reason might causing it?

 - My current video_aclk is set to 100MHz which seems to be enough. With linerate set to 768Mbps, and set to 4 lanes (2 lanes set to active only):

    video_aclk = 768M* 4/(8*4) = 96 MHz(if using 4 lanes) or 48MHz(2 lanes active period)

karnanl
Xilinx Employee
Xilinx Employee
779 Views
Registered: ‎03-30-2016

Hello @Way 

Hmmm, this is weird.
I believe Short Packet FIFO is still in full condition, you may need to assert "Soft Reset" to flush the FIFO.
Could you please try that ?
SOFT_RESET_NEEDED.png

BTW, I am assuming that MIPI CSI-2 RX outputs video data at this state.
Could you please check the data. Do you see any unexpected data ?

Regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
709 Views
Registered: ‎10-19-2020

Hi @karnanl 

Assert the soft reset able to help to remove the short packet fifo full. However, it seems like the reset causes the video data output become incorrect as compared to my previous test. Using ILA, the data output is not the expected data. Besides that, I also observed that the Start of Frame(Tuser[0]) and Data valid(Tvalid) is having half a cycle shifting/different. What I meant here is for example Start of frame assert at time 10ns (assumption only). But, the tvalid is asserted at about 12ns (here assume that the clock period is 4ns). It seems like we cannot simply assert reset when everything is up and running?

Another strange behavior observed today was when I removed the code that sampling the csirx register value, I saw the StreamLineBuffer full bit is set in the interrupt status register. The stream line buffer full causes the CSIRX IP stop process the stream data.  I do not see this behavior in previous test with the code that having sampling the csirx register value. Based on the calculation on video clock mentioned in previous post, the video clock frequency should be enough.

Hence, I feel strange whereby why there is such a differences when I just remove the code that perform sampling to the csirx register. Wonder if do you have any suggestion regarding this?

0 Kudos
Way
Adventurer
Adventurer
655 Views
Registered: ‎10-19-2020

Hi @karnanl 

While I further debug the issue, I notice that the camera sensor initialization contain coding that set the camera sensor to Preview(640*480) first, then Video(1280*720) and then Capture mode (2592*1944). Previously, there is error bit set in the interrupt status register with this flow of initialization. 

Once I tried to comment out part of the code to get the sensor only set to one mode, it appear that the Preview and Capture mode do not see any error bit set in the interrupt status register. However, there is some SoT, ECC error bit when sensor is set to video mode only.

Initially I thought is it linerate issue due to different resolution, but when Preview or Capture mode is set in camera sensor, there is no error bit set in the interrupt status register. Hence, I would like to ask if do you have any suggestion what might causing this behavior?

karnanl
Xilinx Employee
Xilinx Employee
637 Views
Registered: ‎03-30-2016

Hello Way

> I notice that the camera sensor initialization contain coding that set the camera sensor to Preview(640*480) first, then Video(1280*720) and then Capture mode (2592*1944). Previously, there is error bit set in the interrupt status register with this flow of initialization.

Thanks for sharing this.


>Once I tried to comment out part of the code to get the sensor only set to one mode,
    Preview mode (640*480*90fps) = No error in ISR
    Video mode (1280*720*60fps) = SoT, ECC error bit asserted
    Capture mode (2592*1944*15fps) = No error in ISR

Since MIPI CSI-2 RX does not report any error in "Capture mode" which has the fastest line-rate (768Mbps x 2lane), I don't think this is signal integrity issue.
Right now, I am not sure why only "Video mode" reports SoT/ECC error, but I have a few concerns.

MIPI_CSI-2_RX_Unsupported_feat.png
1. Xilinx MIPI CSI-2 RX ( and MIPI D-PHY RX) does not support dynamic.
   So, basically we recommend users to configure MIPI CSI-2 RX IP line-rate to match MIPI D-PHY line-rate that sensor is actually sending. 

   Could you please double check with sensor distributor to find out if sensor is changing line-rate setting depends on video mode ?
   Would you able to test MIPI CSI-2 RX IP with line-rate setting for sensor's "Video mode" ?

2. When in Video mode, is your sensor using 1-lane or 2-lane ?
    Are MIPI D-PHY RX data lanes "PKT_CNT" register incremented as expected ?
    ( MIPI CSI-2 RX "active lane setting" should be configured according to sensor output setting )

 

Kind regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
Way
Adventurer
Adventurer
618 Views
Registered: ‎10-19-2020

Hi @karnanl 

Regarding the frame rate for each resolution, I not sure if it is like the one that mentioned in your previous post. According to the comment in the software, it seems like the resolution for 640*480 is having 15fps whereas there is no comment for resolution 1280*720 regarding the frame rate. For 2592*1944, the frame rate is 15fps as per comment written in the software. The datasheet for ov5640 doesn't show much on how to properly calculate the frame rate based on the PLL setting. Hence, I just follow the comment mentioned in the software provided. I think probably line rate setting is not the issue because resolution 640*480 is ok with the line rate setting.

I tried to lower down the linerate but I am still seeing the same issue during video mode. I am still not able to check with sensor distributor and hence I do not have the exact answer regarding the line rate setting.

All three mode are using two lanes. The PKT_CNT register in DPHY is incremented and active lane is configured to 2 which match the lanes used in sensor.

karnanl
Xilinx Employee
Xilinx Employee
544 Views
Registered: ‎03-30-2016

Hello @Way 

Thank you for sharing those information.

I am not sure why ISR register report errors with "Video mode" only. (while Preview/Capture mode is working just fine)
Perhaps the input signal quality is not good with "Video mode" (?!)
If MIPI CSI-2RX (or MIPI D-PHY RX) reports SoT/SoT sync error , usually we need to check the input signal quality.

See also this Forum post.
https://forums.xilinx.com/t5/Video-and-Audio/problem-with-mipi-csi-2-FPGA-Compatible-D-PHY-Receiver/m-p/1218658#M37227

This forum user is using OV9282, the MIPI on his board has difficulty to transit between LP->HS mode.
He solved the issue , by modifying sensor output drive strength.

If you cannot check the line-rate, maybe you should capture and compare the signal quality between Preview/Video/Capture mode to get some hints.
Do you see any signal quality difference ?


Kind regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
Way
Adventurer
Adventurer
520 Views
Registered: ‎10-19-2020

Hi @karnanl 

Thank you for all the support and suggestion given. Appreciate that.

I tested the input signal from sensor for video mode and it appear that the input signal seems to be having some problem. Looking at the LP->HS transition, the signal appear to be not correct. I tried to search for any setting from the web and modified the setting. After that, the issue is solved and I observed that the input signal during LP->HS is ok. 

karnanl
Xilinx Employee
Xilinx Employee
471 Views
Registered: ‎03-30-2016

Hello @Way 

>After that, the issue is solved and I observed that the input signal during LP->HS is ok.

I am glad to hear that you have found the root-cause. Thanks for your update.

Kind regards
Leo


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos