did you already probe the MIPI signaling to verify the high-speed signaling?
according to the error logs.. uncorr_err: request timed out after 2500 ms
it means there’s no validate frames received by VI engine.
let’s examine your Sensor Pixel Clock, which must be set correctly to avoid potential issues.
FYI, I usually using sensor CSI lane output rate.
for instance, pixel_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel
For pix_clk_hz, we used 6960×560×10 = 38.976 MHz; vendor cited ~600M per lane. Using your formula with 600 Mbps/lane, 4 lanes, RAW12 → 200 MHz. So, should we set pix_clk_hz from lane rate and then set line_length/frame_length so that line_length × frame_length × fps equals that value?
The dts file is as follows named tegra234-p3737-lidar-csi67.overlay.txt
I have a try to configure pix_clk_hz as 200MHz and VI now returns 6960×560 buffers after pix_clk_hz=200 MHz, but frame content is mostly empty (5/560 rows)
With active_h = 560, is frame_length = 2874 (implied by 200 MHz and line_length = 6960) correct, or should VTS = 560 with a different line_length so that line_length × VTS × fps = 200 MHz?
discarding frame reported to indicate a frame has dropped due to invalidate capture state.
let’s enable VI tracing logs to obtain more details.
you may
see-also Topic 349718 for some VI tracing logs with a success image capture as an example.
please note that, here must be one pair of CHANSEL_PXL_SOF/CHANSEL_PXL_EOF to indicate a frame has detected by VI engine. afterwards, it’s ATOMP_FRAME_DONE to indicate it’s complete writing a frame to memory.
for instance,
Does this log indicate that MIPI has already entered Orin, but VI has received almost less than one frame of 6960 × 560, and the frame boundary and DT programming do not match. And then what should I do?
it dose looks like some MIPI data has received by VI. however, there’re some error reported.
for instance, kworker/7:2-150 [007] ....... 1271.227749: rtcpu_nvcsi_intr: tstamp:40324658582 class:CORRECTABLE_ERR type:PHY_INTR phy:3 cil:0 st:0 vc:0 status:0x00000110 kworker/7:2-150 [007] ....... 1271.227749: rtcpu_nvcsi_intr: tstamp:40324658582 class:CORRECTABLE_ERR type:PHY_INTR phy:3 cil:1 st:0 vc:0 status:0x00000110
it shows PHY interrupts. the error code 0x110 means data-lane FIFO overflow.
please see-also similar topics for digging into data-lane FIFO overflow failures. such as… Topic 209574, and Topic 242054.
Did you mean that there is something wrong with the configuration of the device tree, like line_length,pix_clk_hz or others.
The device tree file is as follows. Please help me confirm if there are any issues with the device tree and which parameters need to be confirmed from the snesor supplier. Thank you.
The resolution is 6960x560, the frame rate is 10fps, the image is RAW16, and the MIPI rate is 600M/lane.
just an FYI, line_length is pixel line width horizontal timing size for the sensor mode. Used to calibrate the features in the camera stack. the value must be greater than or equal to active_w.
did you tried the commands to boost all the clocks.
for instance,
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate