I’m getting an uncorr_err: request timed out after 5000 ms.
I’m pretty sure that previous attempts were successful since we are able to capture the desire camera images. But once we get the “uncorr_err: request timed out after 5000 ms”, it stops working and image capture fails from then on.
Apr 16 16:57:09 sdj-rogue-04 kernel: [ 3038.401991] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 5000 ms
Apr 16 16:57:09 sdj-rogue-04 kernel: [ 3038.402018] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
Apr 16 16:57:09 sdj-rogue-04 kernel: [ 3038.402877] (NULL device *): vi_capture_control_message: NULL VI channel received
Apr 16 16:57:09 sdj-rogue-04 kernel: [ 3038.402884] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=4, csi_port=4
Apr 16 16:57:09 sdj-rogue-04 kernel: [ 3038.402889] (NULL device *): vi_capture_control_message: NULL VI channel received
Apr 16 16:57:09 sdj-rogue-04 kernel: [ 3038.402893] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 4 vc- 0
Apr 16 16:57:09 sdj-rogue-04 kernel: [ 3038.417951] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
Although it says that the capture channel was successfully reset, the error keeps repeating.
It’s looks like the sensor driver wrong inappropriate REG by the CID function cause the NVCSI unable capture frame data from the sensor.
You may need to modify the CID function in sensor driver to clarify it.
Thank you ShaneCCC,
Can you be more specific how to change these parameters? I’m new to the Jetson and not familiar how to change the CID function and where the sensor driver is located.
Also, is there an explanation of why my original parameters work >95% of the time, but sometimes fails?
I don’t know if it’s relevant but I’m running JetPack 5.
What’s the APP? What’s the version?
The application is a home grown biotech instrument that takes many images of bio samples. The version of the Jetson is a Santa Clara Model: P3701
Embedded system module 900-13701-0040-000
I mean the BSP version?
cat /etc/nv_tegra_release
nvidia@sdj-rogue-04:~$ cat /etc/nv_tegra_release
R35 (release), REVISION: 4.1, GCID: 33958178, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug 1 19:57:35 UTC 2023
Do you verify capture by v4l2-ctl?
I think you need consult to vendor for the sensor driver debugging.
Thanks
Hi,
One useful first step is to isolate the issue from your application and validate the V4L2 capture path directly.
Could you try capturing a few frames with v4l2-ctl using the same format/resolution/framerate your application is using? For example:
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=10 --stream-to=/tmp/capture.raw --verbose
(Please adjust /dev/video0 if it’s not the correct device)
If this works, the kernel driver, VI/CSI path, and sensor configuration are probably functional, and the issue is more likely in the application capture setup: buffer handling, selected format, selected resolution, framerate, memory type, or timing.
If it fails or gets stuck after some time → the issue is in the driver / HW / CSI pipeline.
Additional sanity check with GStreamer. You can also try a simple pipeline:
gst-launch-1.0 v4l2src device=/dev/video0 ! fakesink
If this shows the same behavior after some time, it further confirms the issue is below the application level.
RidgeRun has some related Jetson camera/V4L2 references that may help with this debugging flow:
https://developer.ridgerun.com/wiki/index.php?title=V4L2_drivers_available_for_Jetson_SoCs
https://developer.ridgerun.com/wiki/index.php?title=OmniVision_OV5647_Linux_driver_for_Jetson_TX2_(Auvidea_J120)
Enrique Ramirez
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com
thank you enrique. I’ll have to wait until the equipment becomes available to me, so I’ll comment after I’ve had a chance.
It looks like the capture is working fine:
nvidia@sdj-rogue-04:~$ v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=10 --stream-to=/tmp/capture.raw --verbose
VIDIOC_QUERYCAP: ok
VIDIOC_REQBUFS returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq: 0 bytesused: 16588800 ts: 261592.653850 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 16588800 ts: 261592.687176 delta: 33.326 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 2 bytesused: 16588800 ts: 261592.720503 delta: 33.327 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 3 bytesused: 16588800 ts: 261592.753829 delta: 33.326 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 4 bytesused: 16588800 ts: 261592.953788 delta: 199.959 ms fps: 13.34 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 5 bytesused: 16588800 ts: 261592.987115 delta: 33.327 ms fps: 15.00 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 6 bytesused: 16588800 ts: 261593.020441 delta: 33.326 ms fps: 16.37 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 7 bytesused: 16588800 ts: 261593.087094 delta: 66.653 ms fps: 16.16 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 8 bytesused: 16588800 ts: 261593.120421 delta: 33.327 ms fps: 17.15 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 9 bytesused: 16588800 ts: 261593.153747 delta: 33.326 ms fps: 18.00 (ts-monotonic, ts-src-eof)
But the GStreamer is not:
nvidia@sdj-rogue-04:~$ gst-launch-1.0 v4l2src device=/dev/video0 ! fakesink
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.000065280
Setting pipeline to NULL …
Freeing pipeline …
nvidia@sdj-rogue-04:~$
Great it seems v4l2-ctl application is working fine. So, the problem could be in your application. I suggest you to check your application and try to reduce it to run a minimal capture test (as we are doing with v4l2-ctl).
I think Gstreamer would not work depending on the frame format/size. For example if you are testing Bayer 10-bits format it won’t work because Gstreamer only supports 8-bit format by default. A patch like this would be needed to get the raw capture:
https://developer.ridgerun.com/wiki/index.php/Compile_gstreamer_on_Jetson_TX1_and_TX2#Steps_to_patch_GStreamer_to_support_RAW10
However, if you are using this format it would be better to try the nvarguscamerasrc element which can capture the raw data and convert it to NV12 format.
gst-launch-1.0 nvarguscamerasrc num-buffers=10 ! fakesink silent=false -v
Which format a you testing?
Enrique Ramirez
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com
Thank you. I will have to struggle with this a bit more, but the suggestions here have allowed me to proceed and test more thoroughly. The fact that it’s working MOST of the time for me is probably indicative of something in our application going bad.