Then I executed the i2c tool to reconfigure the max96712 and max96705 . At this point, the four v4l2 cmd
will no longer refresh. Because I configured the camera, the video stream was interrupted.
After completing the configuration of my i2c tool, the four v4l2 cmd began to refresh the frame rate again.
In some cases, after the reconfiguration is completed, the v4l2 cmd may not continue to refresh the frame rate.
If I Ctrl+C to turn off this v4l2 command, the system will freeze. The stuck log is the same as the topic below
We are using Jetpack 5.0.2. According to the above instructions, we performed the same operation on the orin64g version(jetpack 5.1.1). Discovering that the system will still freeze
The corresponding log is as follows.
Please help to see how to solve this problem dmesg.log (155.6 KB) kern.log (213.4 KB)
as you can see, there’re timeout failures when you’ve interrupt the video stream.
Jul 6 15:22:23 orin-master kernel: [249373.354268] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
Jul 6 15:22:23 orin-master kernel: [249373.354270] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
may I know the failure rate?
there’s internally 2500ms timeout, and it may take couple of seconds to restore capture engine.
may I also confirm how long had you waited to confirm v4l cmd cannot continue to refresh the capture?
besides, could you please also test again by adding bypass_mode setting to your v4l pipeline,
for example, $ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap
I didn’t do detailed statistics, but I think the frequency is quite high. Actually, I didn’t mean to reconfigure the camera registers when reading frame rates. Our orin has a very low probability of crashing and restarting, but I just found that this operation can cause orin to crash more frequently.
From a system perspective, even if the orin cannot read image, it should not crash.
Usually, 96712 is connected to a 4-way camera. After I reconfigure the registers, several of them can continue to refresh the fps normally, but one of them cannot refresh, I will wait for a few seconds and use Ctrl+C
use bypass_mode the system still crash when I use ctrl+c on a no reflashed v4l2 cmd
here shows test steps in brief. we cannot reproduce this locally.
step1) launch gst pipeline to enable camera preview $ gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM),framerate=30/1,format=NV12' ! nvvidconv ! xvimagesink
step2) sending commands on the terminal to shutdown the stream, # cd /sys/kernel/debug/camera-video0 # echo 0 > streaming
I don’t know if there are any similarities or differences between our two different operations on the system low level driver . I couldn’t find the streaming port in my debug port. So I can’t operate your way.
But from my understanding, this error should be a low-level system error. Can you analyze anything in the log I provided. And what else can I do to help troubleshoot this issue
please download the attached camera firmware, Jul13_camera-rtcpu-t234-rce.img (525.3 KB)
assume you already have Jetpack environment setup, you should update rce-fw binary file, $OUT/Linux_for_Tegra/bootloader/camera-rtcpu-t234-rce.img
after that, you may perform partition flash to update camera firmware for your AGX Orin,
i.e. $ sudo ./flash.sh -r -k A_rce-fw jetson-agx-orin-devkit mmcblk0p1
please reproduce the issue again, and also gather the complete kernel logs for reference,
yes, I do the test on jetpack 5.0.2. infact I find the issue show same result on jetpack 5.0.2 and jetpack5.1.1. so I just replace the firmware on jetpack 5.0.2 (Last week, our Jetpack 5.1.1 machine was delivered to the project site.) does the fireware must be test on jetpack 5.1.1?