we have a rather complex setup with two camera modules streaming over one CSI port using virtual channels. Both video devices should stream simultaneously, one goes over libargus using the ISP and the other one is used with v4l2 to get the raw buffer.
Starting each one individually works as expected however trying them out simultaneously leads to a crash of both pipelines.
Is this a known issue or anything we can do about that?
The error on the console is following:
: Module_id 30 Severity 2 : (fusa) Error: InvalidState propagating from:/capture/src/fusaCsiStreamHandler.cpp 248
: SCF: Error InvalidState: (propagating from src/services/capture/FusaCaptureViCsiHw.cpp, function startCaptureInternal(), line 816)
: SCF: Error InvalidState: (propagating from src/services/capture/CaptureRecord.cpp, function doCSItoMemCapture(), line 530)
: SCF: Error InvalidState: (propagating from src/services/capture/CaptureRecord.cpp, function issueCapture(), line 477)
: SCF: Error InvalidState: (propagating from src/services/capture/CaptureServiceDevice.cpp, function issueCaptures(), line 1291)
: SCF: Error InvalidState: (propagating from src/services/capture/CaptureServiceDevice.cpp, function issueCaptures(), line 1122)
: SCF: Error InvalidState: (propagating from src/common/Utils.cpp, function workerThread(), line 114)
: SCF: Error InvalidState: Worker thread CaptureScheduler frameStart failed (in src/common/Utils.cpp, function workerThread(), line 133)
: Module_id 30 Severity 2 : (fusa) Error: InvalidState propagating from:/capture/src/fusaViHandler.cpp 328
: Module_id 30 Severity 2 : (fusa) Error: InvalidState propagating from:/capture/src/fusaViHandler.cpp 468
: SCF: Error Timeout: (propagating from src/api/Buffer.cpp, function waitForUnlock(), line 644)
: SCF: Error Timeout: (propagating from src/components/CaptureContainerImpl.cpp, function returnBuffer(), line 426)
: SCF: Error Timeout: (propagating from src/services/capture/CaptureServiceEvent.cpp, function wait(), line 59)
: Error: Camera HwEvents wait, this may indicate a hardware timeout occured,abort current/incoming cc
FYI,
it’s not always /dev/video0 mapping to sensor-id=0.
Argus side checking for position property to launch camera stream.
for instance, assume in a two-camera system, it’s sensor-id=0 mapping to the device with position = rear.
thanks for the Info, we get images now but only when the resolution of one sensor is set very low. When its set to its full resolution we get errors like this:
ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] "General error queue is out of sync with frame queue. ts=144988197888 sof_ts=145058027744 gerror_code=2 gerror_data=400061 notify_bits=20000"
and argus also seems to crash:
SCF: Error InvalidState: Timeout waiting on frame start sensor guid 0, capture sequence ID = 49 (in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameStart(), line 514)
SCF: Error InvalidState: (propagating from src/common/Utils.cpp, function workerThread(), line 114)
SCF: Error InvalidState: Worker thread ViCsiHw frameStart failed (in src/common/Utils.cpp, function workerThread(), line 133)
SCF: Error Timeout: (propagating from src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameEnd(), line 600)
SCF: Error Timeout: (propagating from src/common/Utils.cpp, function workerThread(), line 114)
SCF: Error Timeout: Worker thread ViCsiHw frameComplete failed (in src/common/Utils.cpp, function workerThread(), line 133)
SCF: Error Timeout: (propagating from src/services/capture/CaptureServiceEvent.cpp, function wait(), line 59)
Error: Camera HwEvents wait, this may indicate a hardware timeout occured,abort current/incoming cc
even lowering the framerate on the sensor does not seem to help and the problem mostly occurs when we start or stop the other sensor while the sensor with high resolution is streaming.
please review your Sensor Pixel Clock settings, it’s camera software uses the sensor pixel clock to calculate the exposure and frame rate of the sensor. It must be set correctly to avoid potential issues.
may I also know what’s the sensor output resolution and frame-rate? how low you revised to make it works?
besides, did you used the latest Jetpack release version, i.e. Jetpack-5.1.2/ l4t-r35.4.1
thanks for the answer! We will try to update to the newest Jetpack, we saw there are some bug fixes for libargus.
Question regarding the Pixel Clock. We would like to use the sensor in different modes, so different resolutions and variable Framerates. How to calculate the Pixelclock then? Should we use the method using the csi output rate? This one should stay the same for all different sensor modes we have.
there’re some calculation formulas in the developer guide,
usually, I used these two to obtain pix_clk_hz for sensor bringup.
for instance,
(1) Using sensor CSI lane output rate: pix_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel
(2) Using frame size and frame rate. pix_clk_hz = sensor output size * frame rate
Yes, thanks. I just wanted to make sure that for all described modes in the device tree the pixel clock stays the same?
Because we saw the problem with higher resolution but not with a low resolution of 1290x720 there the system was stable.
However with full-res 3800x2190 it didnt work and crashed
we moved to the newest JetPack Version 35.4.1 and also checked the sources of the driver. Unfortunally we do not see an improvement and the problem is still there.
I’m closing this topic due to there is no update from you for a period, assuming this issue was resolved.
If still need the support, please open a new topic. Thanks
hello Kewpcool,
please gather the error messages for checking, for instance, $ dmesg > klogs.txt