Capture issues using running single capture for 2 video devices using same CSI port and different Virtual Channel

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hi,

I have a sensor camera driver which supports capture from 2 cameras using the same CSI port and different virtual channel.
I’m using JetPack 4.4.

I have noticed the following strange behavior when capturing with nvarguscamerasrc:

  1. If start the capture for sensor-id=1 (which uses virtual-channel=1), capture works correct and I can stop and restart the streaming without issues.
  2. Then, if I start the capture on sensor-id=0, capture works correct and I can stop and restart the streaming without issues.
  3. After stopping sensor-id=0, If I try to capture again with with sensor-id=1, capture doesn’t work anymore.

When enabling the debug for nvargus-daemon, the error reported is because of no frames arrived after the timeout:
NvCapture) Error Timeout: capture waiting for status timeout (in /dvs/git/dirty/git-master_linux/camera/capture/nvcapture/capture_hw_linux.c, function NvCaptureLinuxGetCaptureStatus(), line 362)

I also ran the same test, but removing timeout restriction (enableCamInfiniteTimeout=1), I saw that no error appears during step 3, but no frames are captured. However, I verified that while capture was hanging for sensor-id=0, if capture was enabled for sensor-id=0`, I was able to capture images from both cameras.

So, basically the problem I have seen is that when sensor-id=0 capture is disabled, capture on sensor-id=1 will not work.

For v4l2 capture, this issue does not appear, however I noticed that if video1 is running and the streaming on video0 is started, the capture on video1 is interrupted for a second and these messages are observed on dmesg output:

[  236.989243] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 160
[  236.989267] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 32, err_data 160

These issues don’t happens if I try to capture from 2 streams using different CSI ports.

I wonder if you have seen this issue before?

Thanks,
-Enrique

3

Looks like the sensor or gmsl/serdes not reset well cause the problem.

4

Hi @ShaneCCC,

Thanks for your suggestion. You were right the problem was related to GMSL chips, I was able to solve the problem by disabling the GMSL video pipe when not streaming.

Thanks,
-Enrique