After the firmware is updated using Topic268833_JP-512_rce-fw.7z, some boards still fail to run video capture for a period of time

Orin nx 8G
JP-5.1.2/l4t-r35.4.1(Unable to use the latest version, because our previous work was based on this version)

Of the 10 modules we bought, 6 worked fine and the other 4 had video stream disconnection after running for a while.
After using the firmware update of Topic 268833 for these four modules, three of them work properly, but one still cannot run stably.(The carrier board is customized, and after cross-verification, it can be determined that the situation is caused by different modules)
Any suggestions?

dmesg.log (19.8 KB)
trace.log (6.0 KB)

hello h1994213,

is it always the same camera? may I know which CSI port is used by this camera.

hi JerryChang,
It can be seen as the same camera, connected to the HDMI to CSI chip (LT6911C) on the carrier board. Two core board modules and two carrier boards are cross-tested, and the anomaly follows the core board.

hello h1994213,

please test with Infinite Timeout Support.
you may also refer to Topic 276217 to apply Argus fixes for set_mode_delay_ms and enable infinite timeout support.

BTW, please double check SerDes Pixel Clock section to review your pixel clock settings.

I just used gstreamer to test video streams: gst-launch-1.0 v4l2src device=/dev/video0 ! ‘video/x-raw, format=UYVY, width=1920, height=1080, framerate=60/1’ ! xvimagesink -ev.

1920*1080 * 60 * 16bpp / 4 lanes, output data rate is < 1.5Gbps.

hello h1994213,

according to tracing logs, there’s no validate frame packets received by VI engine.
could you please try increasing pixel clock slightly for testing?

Use these instructions, right?

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

Hi JerryChang,
Using the above instructions, increase the clock to the maximum, and the exception will still be repeated.

hello h1994213,

for issue narrow down,
are you able to probe the MIPI signaling to confirm there’re validate frame packets on the CSI channel?

Hi JerryChang,
Sorry for not replying in time. I can’t probe the MIPI signal.

hello h1994213,

there’re few camera bugs within early Jetpack-5 release version,
please moving forward to JP-5.1.4/r35.6.0 if there’s no strong request to stay-on JP-5.1.2 for development.

Hi JerryChang,

Thank you for your suggestion! But, I can’t move to JP-5.1.4/r35.6.0.

However, if we can use the super mode, I can try JP6.2 which will be released(The released JP6.1 BSP lacks super mode related files ).

So, I’ll get back to you later.