Hi Jerry Chang：
After I made the modifications, the printed log and trace log are as follows:
I don’t know how to make the changes, please guide me, thank you!!
hello lixiaodonglove7,
you may refer to Sensor Pixel Clock section for several ways to obtain the sensor pixel clock rate. FYI, I usually using sensor CSI lane output rate for calculation.
it looks there’s no camera frame related signaling according to VI tracing logs,
please double check your SerDes chip is actually sending out the sensor signaling to Orin platform.
let me share you VI tracing logs with a success image capture as an example.
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.
rtcpu_vinotify_event: tstamp:4058867917 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:129874754944 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206674 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:129891804896 data:0x0000000800000000
rtcpu_vinotify_event: tstamp:4059206818 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:129891808928 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206976 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:129891815424 data:0x0000000008020001
rtcpu_vinotify_error: tstamp:4060164160 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:1 vi_tstamp:129925171392 data:0x00000000000000a0
rtcpu_vinotify_event: tstamp:4060166846 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:129923836800 data:0x0000000004370002
rtcpu_vinotify_event: tstamp:4060167015 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:129923837312 data:0x0000000000000000
BTW, you may also try below commands to boost the clocks to ignore system level config.
for example,
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/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/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
Hi Jerry Chang：
I configured it as per your guidance, but the effect is still the same, and the SOC did not receive any data.
However, there is something I need to feedback to you. Our hardware engineer encountered an issue while measuring the soc mipi signal. They inadvertently touched some pins, and the screen displayed a complete image, but then it got stuck and no longer displayed any images.
Next, how should I continue to investigate and modify?
hello lixiaodonglove7,
I assume it’s due to the regulator settings, please double check the board schematic and ensure you’ve assign them correctly within device tree.
Did you check and follow (with any adaptations necessary for use with Jetson Orin Nano) deserializer connection example in NVIDIA Jetson AGX Xavier Series and Jetson AGX Orin Series Camera Module Hardware Design Guide Log in | NVIDIA Developer ?
Hello，sgursal：
Yes, we found some issues with our hardware circuit in 4-lane mode. So we can only use the CSI1 2-lane mode for debugging, configuring both the deserializer and the SoC to 2-lane mode and using CSI1-CLK as the clock input. This should be fine, right?
In this scenario, the deserializer can currently output normally in 2-lane mode, but the SOC cannot receive data.
May I ask how to check and fix this?
The following are the eye diagrams of the 2-lane clock and data.
Hello，sgursal and Jerry Chang：
The above image shows the image data I obtained using the gst-launch command. I only captured one frame, and in this image, there is a green part inside the red box at the end.
By checking the log, it seems there is no FE data.
Can this phenomenon indicate the following points:
1. The GMSL data link has been established?
2. The DTS configuration seems to be correct?
Checked through the log, tag: CHANSEL_NOMATCH data: 0x00000000000003c9。
What caused this error?
The following is the complete captured log.
[Serial-COM11]2025-0930-1529-17.log (981.0 KB)
Please help analyze why the video stream is stalling. How should I troubleshoot and fix it?
thanks ！
Hello，sgursal and Jerry Chang：
The above image shows the image data I obtained using the gst-launch command. I only captured one frame, and in this image, there is a green part inside the red box at the end.
By checking the log, it seems there is no FE data.
Can this phenomenon indicate the following points:
1. The GMSL data link has been established?
2. The DTS configuration seems to be correct?
Checked through the log, tag: CHANSEL_NOMATCH data: 0x00000000000003c9。
What caused this error?
The following is the complete captured log.
[Serial-COM11]2025-0930-1529-17.log (981.0 KB)
Please help analyze why the video stream is stalling. How should I troubleshoot and fix it?
thanks ！
hello lixiaodonglove7,
it also looks like incorrect active height has configured in your sensor device tree.
the last part (below green line) seems like the next frame’s top-of-frames. please double check your sensor stream and SerDes chip configuration.