Nano camera capture error: video4linux video0: frame start syncpt timeout!0

Autonomous Machines Jetson & Embedded Systems Jetson Nano
#1

We used imx296+fpga as csi2 data source, and modify the device tree based on imx274. However, when starting capture, no data can be recvied from the /dev/video0. “dmesg” command shows:
dmesg:
[ 116.984747] video4linux video0: frame start syncpt timeout!0
[ 116.990419] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000000
[ 116.990425] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[ 116.990429] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000010
[ 116.990435] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000041
[ 116.990474] vi 54080000.vi: settle time reading from props
[ 116.990478] vi 54080000.vi: discontinuous_clk = 1 reading from props
[ 116.990481] vi 54080000.vi: cil_settingtime was autocalculated
[ 116.990485] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10

The clock and data of CSI signal source are measured by oscilloscope，as shown in the following screenshot.

pallas2 296 clk 4ch
pallas2 296 clk 4ch1034×794 128 KB
pallas2 296 data 4ch
pallas2 296 data 4ch1034×794 126 KB

Can you give me some advice on how to debug ?

#3

Have a check the REG CSI1_CSI_CILA_STATUS_0 it shows below error.

CILA_CLK_LANE_CTRL_ERR: Control Error. Set when CIL-A detects incorrect line state sequence on clk
lane

CILA_DATA_LANE0_CTRL_ERR: Control Error. Set when CIL-A detects LP state 01 or 10 followed by a
stop state (LP11) instead of transitioning

#4

Have you try configure the clock as continuous or discontinuous also modify the discontinuous_clock in the device tree to try?

#5

We use CSI4, is it same as CSI0? “port-index” needs to be configured as “4” or other?
port-index = <4>; bus-width = <1>;

NV_Jetson_Nano_Module_Pinmux_Config_Template.xlsm shows

image
image817×286 28.8 KB

#6

port-index means CSI-0,1,2,3,4,5 (CSI-A,B,C,D,E,F)
So CSI4 port-index should be 4
bus-width means lanes configure, usually 2 or 4 lanes.

#7

The problem of no data or “syncpt timeout” is solved, however we get the wrong images. When the width is a multiple of 64, the image is correct. When the width not, each line of the image loses some data. Can you give us some advice?

#8

Set the preferred_stride by v4l2-ctl to try.

#9

As follows, TX1_TRM shows that SURFACE0_OFFSET_MSB or SURFACE0_OFFSET_LSB only supports 64Bytes atom aligned. Can VI or CSI support other byte alignment, such as 4 / 8 / 16 / 32 , and how to cofigure it.

image
image893×612 38.3 KB

#10

The surface offset aligned can’t be configure. Have you try the preferred_stride?

#11

Yes, preferred_stride only seems to affect the bytes_per_line through the vi&csi driver code. We have modified the width and height alignment to implement requires. After the modification, bytes_per_line is always same as width without any alighment.
image

#12

VI & CSI stride registers must be set as multiple of 64 ?

#13

Suppose, Yes.
What’s your resolution. What kind of tools to check the image?

#14

We used imx296 which resolution is 1440x1080. Capture Image was saved as .pgm, which can be opened by ImageMagick on Ubuntu16.04.

When image was saved by 1440x1080, tools shows (Sensor generates testing image):

image
image948×724 13.4 KB

When image was saved by 1408x1080, tools shows:

image
image938×642 10.2 KB

It seems like 1408x1080 image is correct, and 1408 is multiple of 64.

#15

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Could you try 7yuv that can adjust the stride.
Could you also the fame dump here to check.