Dual capture issue with Xavier AGX and FpdlinkIII

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
, ,
1

Hello
We are having some issues with dual capture using a Xavier AGX on JP 5.0.2.
The setup is:

  • 2k cameras at 20fps, 12bit pixels and 4 lanes

  • One deserializer board

  • Xavier AGX devkit

We are migrating from JP 4.6.1 to JP 5.0.2. We modified the serdes_clk on dev-tree to match the new spec, and one camera works fine, no artifacts or errors on the video. Same as if we test each camera individualy, the stream works fine as long as there is only one one camera in use.
The problem is that when we try to launch 2 streams one of them halts and the other one keeps going. We are using the following pipeline:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=2880, height=1860, framerate=20/1, format=NV12' ! fakesink nvarguscamerasrc sensor-id=1 ! 'video/x-raw(memory:NVMM),width=2880, height=1860, framerate=20/1, format=NV12' ! fakesink

Also:

v4l2-ctl -d /dev/video1 --set-fmt-video=width=2880,height=1860 --set-ctrl bypass_mode=0 --stream-mmap

and

v4l2-ctl -d /dev/video0 --set-fmt-video=width=2880,height=1860 --set-ctrl bypass_mode=0 --stream-mmap

It does not matter if the launch is on separate consoles, or if there is some time between them.

Here what we tried:

  • boost with jetson_clocks
  • boost the capture clocks with:
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
  • export enableCamInfiniteTimeout=1
  • Increase CAPTURE_TIMEOUT_MS on /kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c

Logs:

kernel with gst-launch: 

[RCE] VM0 deactivating.VM0 activating.ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] “General error queue is out of sync with frame queue. ts=1035748457952 sof_ts=1036098803040 gerror_code=2 gerror_data=a0 notify_bits=4”

kernel with v4l2: 
[  772.585775] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: flags 2, err_data 0

[  772.608771] [RCE] VM0 deactivating.VM0 activating.VM0 deactivating.VM0 activating.ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] “General error queue is out of sync with frame queue. ts=795989042016 sof_ts=796089398016 gerror_code=2 gerror_data=a0 notify_bits=4”

[  775.104703] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms

[  775.104952] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel

[  775.105857] (NULL device *): vi_capture_control_message: NULL VI channel received

[  775.106024] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0

[  775.106271] (NULL device *): vi_capture_control_message: NULL VI channel received

[  775.106418] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 1

[  775.106892] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel

Traces: link

Did I miss something else that needs to be modified so the driver can work on JP 5?

Also as a note, after the problem occurs, we need to restart argus-daemon, otherwise we cannot launch a stream. Also dual capture was working on JP4, with jetson_clks and the enableCamInfiniteTimeout=1 export

3

hello andres.artavia,

may I know what’s the output data rate?

note, deskew calibration is the major difference between JP-4 and JP-5.
deskew calibration is a must if data-rate > 1.5 Gbps, Else the camera firmware will continue to wait for deskew signal from the sensor side. it’ll enable pixel parser when deskew calibration has completed.

4

Hi @JerryChang , thanks for the quick response. I think that’s the problem then, since we are using 1.6Gbps data rate.

5

hello andres.artavia,

please start with v4l2 pipeline.
as for now, we got an issue that V4L v.s. Argus were having different timing for waiting deskew signal. the comparison result shows it’s Argus waits for signal too early.
you may test with V4L pipeline to check the stream status. then, it’s able to workaround by configure sensor state as standby (not streaming), then switch the sensor state to stream after you see the RCE deskew setup debug logs.
(i.e. [RCE] Deskew setup message sent for port 0 num_lane 4..)

BTW,
you may see-also Topic 226574 to download JetPack-5.0.2/l4t-r35.1 camera firmware with debug flag enabled.
this debug firmware also helps to dig into the issue, please have this applied to bring-up the camera.
thanks

6

hi, @JerryChang , thanks for the tip on the skew calibration, now it works fine.

8

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