We’re trying to bring up camera system with Xavier and run into issue that Xavier doesn’t seem to receive valid CSI-2 frames (thus cannot display video stream). However, when connecting camera CSI-2 to MIPI analyzer, it can capture correct 1080p image. Probing the signals on clock lane and 4 data lanes on Xavier shows no anomaly.
Below is top part of the trace log. Can you please help to tell what’s wrong with our setup? Thanks.
may I know what’s your commands to access the sensor stream.
could you please check Applications Using V4L2 IOCTL Directly to use V4L2 IOCTL to verify basic functionality during sensor bring-up.
according to your tracing logs, it indicates there’s no response from VI engine.
could you please review your Port Binding definition for VI, NvCSI, and sensor modules.
thanks
With the camera connected directly to Xavier, we can see video stream using gst-launch command. So, I assume there is nothing wrong with the camera.
When we put an intermediate device between camera and Xavier, we have the issue as described. The intermediate device is acting as CSI-2 repeater that replicates the CSI-2 packets received from camera and sends them to Xavier (In a way, it’s similar to setup using FPD-Link Serializer and Deserializer).
Is there any complication and check point we should pay extra attention to this special setup?
We’re not using SerDes. Our setup with intermediate device is like CSI-2 repeater:
Camera => Intermediate Device [CSI-2 RX → CSI-2 TX] => Xavier
The I2C is connected directly from Xavier to Camera. So, we assume everything is transparent in this setup: whatever camera sends is replicated and sent to Xavier.
Again, when we connect intermediate device CSI-2 TX to MIPI Analyzer, it can capture the image correclty.
We’re not sure what else we might miss in this setup.
assume there’s timing difference, could you please add set_mode_delay_ms into your device tree property.
it could configure the maximum waiting time for the first frame after capture starts, the unit is in milliseconds.
please check Sensor Software Driver Programming Guide for reference,
thanks
the default waiting time is 1500ms for the start-of-frame signaling.
there’s the unit in milliseconds to configure the wait time for the first frame after capture starts, it is used to override the default capture timeout value.
thanks
We tried V4L2 and was able to capture raw image and view it correctly. That means the Xavier receives CSI-2 packets, but somehow it doesn’t work when using Gstreamer.
I have not touched device tree which complicates things on our setup (also because V4L2 works). Can you please review the trace and pinpoint what else could be wrong?
cool, you’re having a huge step to verify camera sensor driver and also its basic functionality.
according to Camera Architecture Stack, nvarguscamerasrc plugin were using different path to access the sensor stream.
you have to define CSI ports/streams, VI channels, pixel parser streams, number of lanes etc… into device tree property. please also review Device Properties and revise those property settings to adapt your sensor device tree.
you may also gather the trace log while enable the gstreamer pipeline for more details.
thanks
Given V4L2 works, do you still think the issue with gst-launch command is related to set_mode_delay_ms? Apparently, Xavier does see incoming CSI-2 frames.
What else do you think could be wrong in this setup?
yes.
please note that,
v4l2 standard controls and nvarguscamerasrc plugin were taking different path of code-flow.
nvarguscamerasrc depends-on mostly sensor properties definition from device tree, such as mode properties, signal properties, and image properties.
you may also gather VI tracing logs while enable the stream with nvarguscamerasrc for reference,
thanks
I did not see obvious errors according to your tracing logs. (debug trace gstreamer.txt (1.2 MB))
actually, there’re SOF/EOF signaling, frame-number and also VI timestamps has also reported. your camera stream should be works.
for example,
It’s good to hear that. However, the problem we are facing is no image/video at all when doing gst-launch command. We only see the new window popping up with no image/video, and it’s just hang there.
Is there any specific criteria the nvarguscamerasrc plugin requires from incoming csi-2 frames to display it correctly?
I’ll share the messages when launching gstreamer soon.
There is a note in Gstreamer User Guide: “The nvoverlaysink plugin is deprecated in L4T Release 32.1. Use nvdrmvideosink and nv3dsink instead for render pipelines with gst-v4l2 decoder.”
Will it work with R32.3.1?
Anyway, I’ll give it a try to see if there is any difference.
It happened that the previous trace log was recorded when doing gst-launch after a v4l2 command. Today I found that even after v4l2 command stops, the stream continues. So the previous trace log was actually for v4l2, which we knew working. Sorry for the inconvenience.
I dump the trace log again right after power on to avoid above situation. It doesn’t show any valid frames. I did it with both vximagesink and nvoverlaysink and result is the same.
Attached are trace log with terminal message for both cases. They are much smaller. Can you please help to review it and tell us what could be wrong?