MIPI CSI frame discard : FPGA Connected with AGX-Orin

Hi team,

We have worked on AGX-Orin kit and faced issue in CSI - interface with FPGA.

We run v4l2 command and CSI frame packet dropped as below-

#v4l2-ctl --stream-mmap -c bypass_mode=0
<<<<<<<<< 22.20 fps, dropped buffers: 16
<<<<<<< 22.20 fps, dropped buffers: 14
<<<<<<<< 22.20 fps, dropped buffers: 16
<<<<<<< 22.20 fps, dropped buffers: 14
<<<<<<<< 22.20 fps, dropped buffers: 16
<<<<<<< 22.20 fps, dropped buffers: 14

dmesg log

[ 123.725659] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072 --only this

As per my understanding, The results show that some frames are being discarded, while others are successfully captured.

Please suggest, How to proceed to resolve issue?

Regards,

Niranjan Kumar

*** Please note that this reply is generated by LLM automatically ***

The issue you’re facing with the CSI interface on the Jetson AGX Orin kit is related to frame packet drops. The v4l2ctl command output shows that some frames are being discarded while others are successfully captured.

To resolve this issue, let’s break down the possible causes and potential solutions:

  1. CSI Lane Configuration: Ensure that the CSI lane configuration is correct. The Jetson AGX Orin supports up to 6 CSI lanes. Verify that the FPGA is configured to use the correct number of lanes and that the lanes are properly connected to the Jetson module.

  2. FPGA Configuration: Check the FPGA configuration to ensure that it is properly set up to transmit data to the Jetson module. Verify that the FPGA is using the correct clock frequency, data format, and other settings.

  3. Clock Frequency: Ensure that the clock frequency used by the FPGA is compatible with the Jetson module. The Jetson AGX Orin supports clock frequencies up to 1.5 GHz.

  4. Data Format: Verify that the data format used by the FPGA is compatible with the Jetson module. The Jetson AGX Orin supports various data formats, including RAW12, YUV422, and others.

  5. Virtual Channel ID: If you’re using a GMSL deserializer, ensure that the virtual channel ID is properly configured. The virtual channel ID is used to multiplex multiple sensor streams over a single CSI port.

  6. Device Tree Configuration: Verify that the device tree configuration is correct. The device tree configuration defines the CSI port, lane configuration, and other settings.

  7. Firmware Version: Ensure that the firmware version on the Jetson module is up-to-date. You can check the firmware version using the nvfw command.

  8. Hardware Issues: If none of the above solutions work, it’s possible that there’s a hardware issue with the FPGA, Jetson module, or the CSI interface.

Comparison with other Jetson modules:

  • The Jetson AGX Xavier series also supports CSI interfaces, but the lane configuration and clock frequency may differ.
  • The Jetson Xavier NX series has a similar CSI interface configuration to the Jetson AGX Orin, but the clock frequency and data format may differ.

To further troubleshoot the issue, you can try the following:

  • Use the v4l2-ctl command to capture frames and verify that the frames are being dropped.
  • Use the dmesg command to check for any error messages related to the CSI interface.
  • Use a logic analyzer to verify that the CSI signals are being transmitted correctly.
  • Try using a different FPGA configuration or a different Jetson module to isolate the issue.

By following these steps, you should be able to identify and resolve the issue with the CSI interface on the Jetson AGX Orin kit.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

hello niranjan.kumar1,

you may try to specify the sensor supported formats to the v4l pipeline.
please check sensor capability with.. $ v4l2-ctl -d /dev/video0 --list-formats-ext
here’s sample v4l pipeline for fetching frames from 1920x1080 sensor mode.
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

Hi Jerry,

Thanks ! for response

FPGA CSI sensor suppoted UYVY422 - 8 bit

v4l2 command response as below-

hello niranjan.kumar1,

here’s one thing strange, the sensor capability report 60-fps, but your v4l pipeline only reaching 22-fps.
we’ve also tested with YUV camera sensor on AGX Orin to confirm VI driver for fetching UYVY stream works normally.
it should be the issue with your sensor driver, please debug into it.

Hi JerryChang,

Thanks for the update. I am working with “niranjan.kumar1”.

trace_500Mbps_1Lane_MIPI_CSI.log (38.0 MB)

Our setup involves an FPGA-based MIPI CSI-2 Hard D-PHY transmitter, which is self-driven and does not require an I²C interface for configuration.
So in the driver, the I²C part is ignored. Here we are using single lane MIPI to test the device which is configure on dts file.
In the sensor driver source code, the FPS (frames per second) is set, which can be retrieved using the command v4l2-ctl -d /dev/video0 --list-formats-ext.

static const int fpga_dev_60fps = {
60,
};

static const struct camera_common_frmfmt fpga_dev_frmfmt = {
{{1920, 1080}, fpga_dev_60fps, 1, 0, 1 },
};

/* this gets plugged into struct camera_common_data when you do
camera_common_initialize() inside your probe. */

static struct camera_common_sensor_ops dummy_common_ops = {
.numfrmfmts = ARRAY_SIZE(fpga_dev_frmfmt),

We are enable the trace in following way to debug the driver and media pipeline
modprobe rtcpu_debug

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 3 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace

v4l2-ctl --stream-mmap -c bypass_mode=0

cat /sys/kernel/debug/tracing/trace

Result 0f cat /sys/kernel/debug/tracing/trace - (Details log is attached).

Kindly check the log and Could you please suggest further steps to debug?

Thanks!

hello yogesh.jotava,

may I know how many sensor modes within your driver?
we usually used enum to define mode index, its default value will be 0 if not initialized explicitly.
for instance,
$public_sources/kernel_src/kernel/nvidia-oot/drivers/media/i2c/imx219_mode_tbls.h

enum {
        IMX219_MODE_3280x2464_21FPS,
        IMX219_MODE_3280x1848_28FPS,
        IMX219_MODE_1920x1080_30FPS,
static const struct camera_common_frmfmt imx219_frmfmt[] = {
        {{3280, 2464},  imx219_21fps, 1, 0, IMX219_MODE_3280x2464_21FPS}, 
        {{3280, 1848},  imx219_28fps, 1, 0, IMX219_MODE_3280x1848_28FPS}, 
        {{1920, 1080},  imx219_30fps, 1, 0, IMX219_MODE_1920x1080_30FPS}, 

hence,
your last column of {{1920, 1080}, fpga_dev_60fps, 1, 0, 1 },, since it’s using 1, it’s point-to the second register mode table.
please double check it’s the same sensor mode you’ve enabled.

Hi JerryChang,

We support only a single mode in our device. As per your suggestion, we updated the driver entry to {{1920, 1080}, fpga_dev_60fps, 1, 0, 0},
and the results are same and as per below:

hello yogesh.jotava,

is it possible to review the sensor driver to confirm it’s actually running at 60-fps sensor mode?

Hi JerryChang,

We are currently using the command v4l2-ctl --device=/dev/video0 --get-parm to check the FPS set by the sensor driver. However, since our FPGA device is self-driven and the sensor driver does not use I2C communication with the sensor device, we understand that we are unable to directly read the FPS value from the hardware. Could you kindly advise if there is any method or calculation to confirm that the sensor is operating in the 60-FPS mode? Additionally, we would appreciate your guidance on where we can add debug points to check how much data (in bytes) the Jetson platform receives per line and per frame.

hello yogesh.jotava,

v4l2 IOCTL it’s checking camera_common_frmfmt to report sensor available formats.
since you’ve using fpga_dev_60fps in the modes, it reports 60-fps to you.

please refer to below VI driver,
$public_sources/kernel_src/kernel/nvidia-oot/drivers/media/platform/tegra/camera/vi/vi5_fops.c

static void vi5_capture_dequeue()
{
...        
        wake_up_interruptible(&chan->start_wait);
        /* Read SOF from capture descriptor */
        ts = ns_to_timespec64((s64)descr->status.sof_timestamp);

it’s VI driver for waiting each start-of-frame to capture a frame,
please give it a try to add some debug messages for checking the timestamp.
you may calculate sensor frame rate from the interval time.

Hi JerryChang,

  1. We executed the command v4l2-ctl --device=/dev/video0 --stream-mmap --stream-count=10 --verbose, and the results are as follows. Is this correct ts (timestamp)? (our configuration is 1920x1080, YUV422 8-bit, MIPI per lane speed is 500Mbps, total Number of MIPI lanes: 1)

  1. We have configured pixel_clk_hz using the formula: sensor data rate per lane (Mbps)number of lanes/bits per pixel, which is 500 Mbps1/16 = 31250000. Is this the correct configuration for pixel_clk_hz?"

hello yogesh.jotava,

it looks you did have couple of frames dropped.
here’s the normal capture result with 30-fps sensor stream.

...
cap dqbuf: 0 seq:      0 bytesused: 16588800 ts: 421532.312869 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 16588800 ts: 421532.346335 delta: 33.466 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 16588800 ts: 421532.379801 delta: 33.466 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 16588800 ts: 421532.413266 delta: 33.465 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      4 bytesused: 16588800 ts: 421532.446732 delta: 33.466 ms fps: 29.88 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      5 bytesused: 16588800 ts: 421532.480197 delta: 33.465 ms fps: 29.88 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      6 bytesused: 16588800 ts: 421532.513663 delta: 33.466 ms fps: 29.88 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      7 bytesused: 16588800 ts: 421532.547129 delta: 33.466 ms fps: 29.88 (ts-monotonic, ts-src-eof)

Hi JerryChang,

Thanks for the quick reply.

How can I determine the reason for Jetson AGX Orin dropping frames by checking specific logs or reading particular registers? This information would be highly beneficial to us.

hello yogesh.jotava,

please follow the steps below to enable VI tracing logs for more details.

modprobe rtcpu_debug
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace

Hi JerryChang,

I am unable to identify the cause of the frame dropping issue from the log. Could you please review the attached trace log and suggest potential causes for the frame drops, so we can focus on addressing them effectively?

trace_500Mbps_1Lane_MIPI_CSI_DT_1_0_0-1.log (67.5 MB)

hello yogesh.jotava,

it shows lots of.. class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004, which means the packet payload CRC check has failed.

besides.. according to the SOF/EOF timestamps, it’s around 67.5ms to process a frame.

rtcpu_vinotify_event: tstamp:6192730175 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:0 vi_tstamp:198157501600 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:6194542192 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:0 vi_tstamp:198225055328 data:0x0000000004370002
rtcpu_vinotify_event: tstamp:6194542345 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:0 vi_tstamp:198225055936 data:0x0000000000000000

for instance,
EOF vi_tstamp 198225055328 - SOF vi_tstamp 198157501600 ~= 67553728 ns
hence.. the frame-rate processed by camera engine is around 14.8-fps.

Hi JerryChang,

Thank you for the valuable insights. I would appreciate it if you could kindly help clarify the following points for better understanding:

  1. Could the failure of the “Packet payload CRC check” be the cause of frames being dropped during video transmission?

  2. When executing the command v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100, the output shows 22.20 fps (with dropped buffers), but the trace log indicates 14.8 fps. Why is there a difference between the FPS reported in the output and the trace log?

hello yogesh.jotava,

please try below commands to boost clocks for testing.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/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/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

besides..
you may also give it a try to ignore frame_err report from the VI driver side for testing.

diff --git a/drivers/media/platform/tegra/camera/vi/vi5_fops.c 
@@ -558,7 +558,7 @@ static void vi5_capture_dequeue(struct tegra_channel *chan,
                                        "err_data %d\n",
                                        descr->status.frame_id, descr->status.flags,
                                        descr->status.err_data);
-                               frame_err = true;
+//                             frame_err = true;

Hi JerryChang,

We have checked with boost clock but same behavior observed.

Kindly clarify the following queries to help us gain a better understanding of the logs:

  1. Could you please clarify the meaning of the error message “CHANSEL_SHORT_FRAME (data:0x0000200001000000)” that we have recently observed? Specifically, we would like to understand the implications of this error and the significance of the accompanying hexadecimal data.
  2. In the trace log message “rtcpu_vinotify_event: tstamp:28900979627 cch:0 vi:0 tag:CHANSEL_SHORT_FRAME channel:0x01 frame:0 vi_tstamp:924831114240 data:0x0000200001000000,” could you please explain the meaning of the keywords “cch:0,” “vi:0,” “channel:0x01,” and “frame:0”? Additionally, could you provide the mapping or significance of these parameters in this context?
  3. If I pass the argument “–stream-count=10” in the V4L2 stream capture command, does it mean that it will capture 10 valid frames, or will it initiate capturing for a total of 10 frames, including any discarded frames? Could you kindly clarify how the “–stream-count=10” argument functions in this context?