Debug PHY_INTR0 phy:0 cil:0 st:0 vc:0 status

[khang.l4es]

Hi Forum,

We are debugging MIPI-CSI2 Rx during the bringing of the a bridge FPGA and below are the trace log in the case of :

1. Discontinuous clock = no

kworker/1:3-113 [001] .... 224.092440: rtcpu_nvcsi_intr: tstamp:7781596223 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000004

which looks similar to this issue AGX Xavier tegra194-vi5 15c10000.vi: no reply from camera processor - #5 by ShaneCCC

I then changed the clock mode to discontinuous as per suggestion in the above discussion.

2. Discontinuous clock = yes

kworker/0:2-85 [000] .... 384.254503: rtcpu_nvcsi_intr: tstamp:12695241622 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x10000004

which can also be found in case 2) of this issue Orin Nano and tc358743 capture issue - #3 by JerryChang

Could someone help to clarify above status, please ?

I am testing Jetpack-5.0.2.

Thanks in advance and best regards,
Khang
trace_discontinuous_clock_no.txt (276.0 KB)
trace_discontinuous_clock_yes.txt (52.7 KB)

[ShaneCCC]

The error tell the SOT(start Of Transfer) multiple bits error.
It could be cause by the incorrect MIPI timing like settle time. You may need to review the pix_clk_hz/serdes_pix_clk_hz

[khang.l4es]

Hi @ShaneCCC,

The error tell the SOT(start Of Transfer) multiple bits error.

Did you mean the status:0x10000004 in the case of discontinuous clock = yes?

It could be cause by the incorrect MIPI timing like settle time. You may need to review the pix_clk_hz/serdes_pix_clk_hz

The MIPI-CSI2 output of the FPGA is with pixel clock of 74,9 Mhz (nominally 74,25MHz). Should I set a approximate value (75MHz) or is there any problem to multiply it with a factor of N (for example 74,25x4 = 297Mhz) ?

[ShaneCCC]

Suppose should follow below calculation.

MIPI clock = pix_clk_hz*depth/lanes

[khang.l4es]

So, for my case :

                            mclk_khz = "24000";
                            set_mode_delay_ms = "5000";
                            num_lanes = "4";
                            tegra_sinterface = "serial_a";
                            phy_mode = "DPHY";
                            discontinuous_clk = "yes";
                            dpcm_enable = "false";
                            cil_settletime = "0";

                            active_w = "1920";
                            active_h = "1080";
                            mode_type = "yuv";
                            pixel_phase = "uyvy";
                            pixel_t = "yuv_uyvy16";

                            dynamic_pixel_bit_depth = "16";
                            csi_pixel_bit_depth = "16";
                            readout_orientation = "0";
                            line_length = "2200";
                            inherent_gain = "1";
                            mclk_multiplier = "30"; // Deprecated !?!?
                            pix_clk_hz = "74900000";

MIPI clock = pix_clk_hz*depth/lanes = 74,9 * 16/4 = 299,6MHz.

And what exactly is the MIPI clock in the device-tree settings?

[ShaneCCC]

The MIPI clocks didn’t set in device tree but NVCSI/VI driver calculate it by pix_clk_hz.

BTW, you can’t only set the discontinuous clock in device tree, you need to configuration the sensor to output as discontinuous clocks or continuous clocks.

[khang.l4es]

Hi @ShaneCCC,

BTW, you can’t only set the discontinuous clock in device tree, you need to configuration the sensor to output as discontinuous clocks or continuous clocks.

We expect the continuous clock mode from the FPGA, but we are waiting for the confirmation from the FPGA designer about that as we are having the issue of receiving the MIPI-CSI2 data during the integration. I switched btw the modes just for debugging and provided additional information to the FPGA designer.

For the calculation you gave, I can configure in the device-tree :

depth = csi_pixel_bit_depth = 16,
lanes = num_lanes = 4,
pix_clk_hz = 74900000

And you said

The MIPI clocks didn’t set in device tree but NVCSI/VI driver calculate it by pix_clk_hz.

So I think that there’s nowhere that I can set the MIPI clocks (aka. sensor data rate per lane (Mbps)) but can only guarantee that it does not exceed the max. value (usually 1.5Gbps/lane). I can only provide the 3 above parameters correctly. Could you confirm if they are correct?

The error tell the SOT(start Of Transfer) multiple bits error.

Also, could you clarify what indicates the SOT(start Of Transfer) multiple bits error?

[ShaneCCC]

I mean you just need to set correct pix_clk_hz don’t need to set the MIPI clock due to NVCSI driver will calculate it by pix_clk_hz than base on MIPI clock to calculate the settle time if you set the cil_settle to 0.

[khang.l4es]

Hi @ShaneCCC,

Thanks for your explanation. Now I have consistent ’ PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x00000004’. Is it the ‘SOT multiple bit error’ you mentioned? If yes, should I still revise the pix_clk_hz or the FPGA output signal?

[ShaneCCC]

If the pix_clk_hz is properly than it could be the sensor output timing issue.

[khang.l4es]

Hi @ShaneCCC,

Could you help to instruct how to access the NVCSI registers (NVCSI_PHY_0_NVCSI_CIL_A_CONTROL_0, NVCSI_STREAM_0_INTR_STATUS_VC0_0) for the HW debugging purpose, please ?

This is quite urgent as we are being stuck/blocked during the integration of the FPGA bridging. To progress, we need to provide more info to the FPGA designer to do some tuning on the Tx side.

Some probably relevant discussion I found is :

Experiencing strange behavior on MIPI CSI2 stream without i2c

Thank you for the hint. The NVCSI_STREAM_0_INTR_STATUS_VC0_0 did not give me any info but in the TRM I found another register (NVCSI_STREAM_3_PF_CRC_0) that could give me the calculated and the received frame CRC. Reading Register NVCSI_STREAM_3_PF_CRC_0 cmd: devmem2 0x15a281d8 w result: /dev/mem opened. Memory mapped at address 0x7f8bca9000. Value at address 0x15A281D8 (0x7f8bca91d8): 0x631EA801 Which showed that the calculated and the received CRC did not match. calculated CRC: 0x631E r…

But I experienced the system hang/crash while trying to access the 0x15a281d8 address with devmem2.

And you said “This REG is in VI scope may need to disable the power gate to access it” in the following discussion Accessing VI_CFG_VGP1_0 register - #6 by ShaneCCC

Could you tell how to do this ?

Thanks in advance and best regards,
Khang

[ShaneCCC]

Reference to below topic to disable firewall to access the REG.

R36.3:how to disable firewall

hello Michaellovemilk, it’s tegra234-mb2-bct-scr-p3701-0000.dts to load firewall config for Orin series. due to the target name has changed to generic since rel-36 release version. hence, you should see the firewall config as following. for exmaple, $OUT/Linux_for_Tegra/bootloader/generic/BCT/tegra234-firewall-config-base.dtsi furthermore, it’s suggested to update the settings via override file, i.e. tegra234-mb2-bct-scr-p3701-0000-override.dts. please include below settings for un-blocki…

[khang.l4es]

Hi @ShaneCCC,

Thanks but the solution you shared was applied for the Orin family and for the jetpack-6.
I am with the Xavier NX and Jetpack-5.0.2 unfortunately.

By the way, by asking the FPGA side to switch to discontinuous clock mode (of course I modified the device-tree to align with that mode as well), there was small progress : being able to capture half of the very fist frame with any launching of gstreamer command, however it then froze.

And the trace :

     kworker/0:4-648     [000] ....   240.308666: rtcpu_nvcsi_intr: tstamp:8341767221 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000008
     kworker/0:4-648     [000] ....   240.308667: rtcpu_nvcsi_intr: tstamp:8341768145 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000008

trace_discontinuous_clock_74900000hz.txt (618.4 KB)

Relevant register according to my searching :

I think there’s still necessary tuning in the FPGA side (MIPI-CSI2 Tx) but I would like to know how to interpret the above error in order to provide info to the FPGA designer, please ?

Best Regards,
Khang

[ShaneCCC]

pd_wc_short_err, basically indicate that the lines sent by the sensor are too short. Error is emitted for every long packet sent by the sensor.