The camera cannot run continuously due to nvargus

Hello,
Today I conducted camera testing on Jetson Orin NX 16GB with JetPack 5.1.2, camera: IMX327
Two of the cameras were tested using the command

gst-launch-1.0 nvarguscamerasrc ee-mode=0 tnr-mode=0 aeantibanding=0 silent=false ! fakesink

while the other one was tested using the vidio-viewer command

video-viewer csi://2 --input-rate=25

However, none of the cameras were able to capture images.
The error message from GStreamer indicated UNAVAILABLE and TIMEOUT.


And I need to restart nvargus,

systemctl restart nvargus-daemon.service

otherwise the new commands cannot access the camera.

This could be due to intermittent MIPI signals, maybe. I would like to know how to test the stability of the camera input signal to verify my hypothesis.

Thank you!

I tried the solution suggested in this post [Jetson Corrupted Frame Camera Driver(Jetson Corrupted Frame Camera Driver).

What I have tried so far:

Run three cameras using different commands, save the results, and export the logs.

  • test with libargus with error handling mechanism
    there’s Argus sample with error handling, and error resiliency, i.e.
    */usr/src/jetson_multimedia_api/argus/samples/userAutoExposure/
    this is result of userAutoExposure.

  • by v4l2 IOCTL to check sensor basic functionality

gst-launch-1.0 nvarguscamerasrc sensor-id=1 ee-mode= 0 enr-mode=0 aeantibanding=0 silent=false ! fakesink

gst-launch-1.0 nvarguscamerasrc sensor-id=2 ! ‘video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12’ ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=I420’ ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v

hello 1010130836,

let’s narrow down the issue here.
had you bring-up this camera yet? is it due to unstable camera stream?
please check Approaches for Validating and Testing the V4L2 Driver.
please use the V4L2 IOCTL to verify basic camera functionality.

My camera is working fine。
The issues mentioned above occurred after running it continuously for three hours.
It has happened frequently before, and the timing is not consistent.

And I am currently still conducting tests.

hello 1010130836,

please apply fixes from Topic 268833 to update deskew algorithm, and also stability fixes.

besides,
is it possible for moving to latest release (i.e. JP-5.1.3) for confirmation?

I will try it Topic 268833 today.

Besides, upgrading the version is the last choice.
It’s better to resolve the issue in the current version if possible.

Thank you for your help!

Hi
I’m sorry for not updating the test results promptly.
Before your response, I tried updating two .so files.

/usr/lib/aarch64-linux-gnu/tegra/libnvscf.so
/usr/lib/aarch64-linux-gnu/tegra/libnfusacap.so

Currently, it has been running for 30 hours.
I want to know how long this can ultimately run and if it can be considered as a solution.

hello 1010130836,

may I double confirm where did you obtain those two binary updates?
long run scenario it depends-on your real use-case, FYI, we’ve test dual IMX219 long-run stream for over-weekend.

ya, that’s looks like related bug fixes we’ve given for r35.4.1

Hi,
As of now, my two Orin NX have been running for 130 hours and 106 hours respectively, which is completely different from before.
I believe the issue has been resolved.
If the issue arises again, I will try the suggestions you have provided.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.