Hi NV team,
I am using max96724+0x5b1s camera in Jeston AGX Orin Devkit. My camera module data format is YUYV.
When I use command “v4l2-ctl -d /dev/video3 --stream-mmap“ to capture the image, error log is below:
~$ v4l2-ctl -d /dev/video3 --stream-mmap
[10540.527542] ox05b1s 31-001c: ox05b1s_start_streaming
[10540.531159] max96717 31-0060: max96717_setup_streaming
[10540.531163] max96724 31-0027: max96724_setup_streaming
[10540.531165] max96724 31-0027: max96724_start_streaming
[10540.531167] max96724 31-0027: max96724_force_csi_out_en
[10540.531173] max96724 31-0027: max96724_read_reg:i2c read 0x8a0 = 84
[10540.531600] max96724 31-0027: max96724_write_reg:i2c write 0x8a0 = 84
[10540.595366] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
[10540.595366] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
[10540.629179] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
[10540.629179] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
[10540.663183] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
[10540.663183] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
[10540.697381] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
video3_vi_trace_fail_0825.log is the kernel tracing log.
~$ v4l2-ctl -d /dev/video3 --list-formats
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture
[0]: 'YUYV' (YUYV 4:2:2)
[1]: 'YUYV' (YUYV 4:2:2)
Would you please help to dig out the problem?
Thanks,
video3_vi_trace_fail_0825.log (230.4 KB)
*** Please note that this reply is generated by LLM automatically ***
Based on the provided information, it appears that you are experiencing issues with capturing images from the max967240x5b1s camera module on the Jetson AGX Orin Devkit. The error log indicates that there are errors related to discarding frames, and the kernel tracing log shows a “vitracefail” error.
After reviewing the provided information, I noticed that the nvv4l2camerasrc plugin is used in the command gst-launch-1.0 nvv4l2camerasrc device=/dev/video3 ! .... However, the nvv4l2camerasrc plugin is currently verified using the NVIDIA V4L2 driver with a sensor that supports YUV capture in UYVY format. Since your camera module data format is YUYV, it may not be compatible with the nvv4l2camerasrc plugin.
To resolve this issue, you may need to enhance the nvv4l2camerasrc plugin to support the YUYV format. Alternatively, you can try using a different plugin or approach that supports the YUYV format.
Additionally, the error log mentions “discarding frame 0 flags 0 errdata 64”. This error message is not specific to the nvv4l2camerasrc plugin, and it may be related to other factors such as the camera module, the V4L2 driver, or the kernel.
To further troubleshoot the issue, I recommend checking the following:
- Verify that the camera module is properly connected and configured.
- Check the V4L2 driver version and ensure that it is compatible with the Jetson AGX Orin Devkit.
- Review the kernel tracing log to identify any potential issues related to the camera module or V4L2 driver.
- Consider using a different plugin or approach that supports the YUYV format.
If you are still experiencing issues, please provide more information about your setup, including the camera module configuration, V4L2 driver version, and kernel version. This will help me provide a more detailed and accurate solution.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
CHANSEL_FAULT of PIXEL_RUNAWAY means VI receives more lines than expected.
Dear Shane,
How could we get such information about the lines that VI receives? And the lines expected?
Whether we can ignore such fault or walk around it, so that we can get the image by expected?
Lines expect is reported by your driver.
Dear Shane,
In this case, would we get the lines number that VI received in the attached log?
Below tell receive more than 0x798 lines.
Maybe boost the clocks to verify if less bandwidth cause the problem.
kworker/9:0-60 [009] .... 1326.066303: rtcpu_vinotify_event: tstamp:42178975519 cch:0 vi:0 tag:CHANSEL_FAULT channel:0x23 frame:0 vi_tstamp:1349726876320 data:0x0000000007980040
sudo su
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
Dear Shane,
From the log
kworker/9:0-60 [009] … 1327.970428: rtcpu_vinotify_event: tstamp:42238993109 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:0 vi_tstamp:1351634364096 data:0x0000000000000001
kworker/9:0-60 [009] … 1327.970429: rtcpu_vinotify_event: tstamp:42239535802 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:0 vi_tstamp:1351664805664 data:0x0000000007970002
so the lines should be right? right? 0x798 —> 1944, that is the expected height.
The CHANSEL_FAULT tell the receive more than 1944 lines. You can modify the sensor driver to report more than 1944 for example 1945, 1946 …
Dear Shane,
After boost the clocks,
832000000
1011200000
642900000
3199000000
err_data is also the same.
[ 723.085518] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
[ 723.085518] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 64
kworker/3:1-4443 [003] … 1402.480734: rtcpu_vinotify_event: tstamp:44573014862 cch:0 vi:0 tag:CHANSEL_FAULT channel:0x23 frame:0 vi_tstamp:1426336371296 data:0x0000000007980040
That tell the doesn’t matter with bandwidth but incorrect size reported cause the problem.
Dear Shane,
What is the next step should we go ahead about this issue? Would you please give me some tips?
Thanks,
I have comment in previous comment to modify your driver to report more lines one by one to narrow down it.
Dear Shane,
After I increase the lines to 1948, then there is no err log when opening the camera.
Discussing with the camera vendor, the external 4 lines data should be the embedded meta data. How could I add the configuration about the embedded line data?
Although there is no err log, but the image show is wrong. the whole image show looks like green. I guess the image format is wrong. it looks like the format is uyvy. Would you please give me some tips about this issue?
Thanks,
Dear Shane,
When I modify the embedded_metadata_height to 4, there is following err below:
[ 3492.764493] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 3492.774746] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 3492.838744] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 262144
[ 3495.571269] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 3495.580412] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 3495.590664] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 3495.660547] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 262144
[ 3498.387231] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 3498.396403] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 3498.406682] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 3498.448432] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 262144
[ 3501.203199] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
video3_emmbedded_err.log (42.1 MB)
Looks like it’s not embedded data line if add embedded_metadata_height = 4 make capture failed.
Maybe check the trace log.
Yes, the color should be incorrect pixel format problem. You can report other format to try.
Dear Shane,
According to the sensor vendor, the embedded line data is the first 4 line on the sensor top data.
The first 2 lines are the sensor embedded data, and the next 2 lines are the ISP embedded data.
So how do the VI analysis such embedded data?
Follow the MIPI spec only the 0x12 data type are embedded data.
