Corr_err: discarding frame 0, flags: 0, err_data 131072

Hi, I am integrating our sensor on the Jetson Orin NX16 development board. The sensor has a resolution of 2560x31, RGGB10 format, and it is connected to the J21 camera interface through an adapter board. Since the imx219 camera provided with the development board works properly, we are utilizing the device tree and driver for imx219 and making necessary modifications for compatibility.
However, during the subsequent integration, we have confirmed that all I2C registers have been written correctly. The measured MIPI clock of the sensor is around 400MHz, and the MIPI data from the sensor can also be observed using an oscilloscope. However, we encountered a failure when attempting to capture the stream using V4L2. The error message is as follows:

Please refer to the log folder for the relevant error messages and strace information. For the device tree and driver, please refer to the dst and driver folders. I look forward to your response.
In addition, based on the information from strace, I have tried modifying the resolution to 2560x32 in both the device tree and the driver. However, the error remains similar. Therefore, currently, I am still using the resolution specified in the sensor’s datasheet, which is 2560x31.
log.txt (6.8 KB)
trace.txt (662.7 KB)
tegra234-p3768-camera-rbpcv2-imx219.dtsi (1.6 KB)
tegra234-camera-rbpcv2-imx219.dtsi (15.5 KB)

hello znghuangyw,

may I know which release version you’re working with?
here’s discarding frame error report by VI, it’s sometime a warning messages, due to unsuccess capture state, it’s dropping frames and issue a requeue for new buffers. according to the logs, flags:0 means channel has encountered uncorrectable error and it must be reset.

hello JerryChang
My platform is Jetson Orin NX 16, with Jetpack 5.10. I would like to confirm if there is a minimum resolution limitation for sensors on NX16. We encountered a situation on other platforms where the resolution cannot be smaller than 32.

Additionally, we measured the MIPI clock signal and found that it has a frequency of around 400 MHz, but the amplitude is only about 30 mV. Will this affect the data reception on the platform?

Please refer to MIPI DPHY specification for the signaling level requirement. At least, the |VOD| should be in the range of 140mV ~ 270mV, VOD = VDP - VDN.

hi,I re-illuminated our sensor on the fixture, and its MIPI clock is around 170-230 mV (as shown in the figure below), which appears to be similar to what I measured on the NVIDIA platform. Additionally, could you help me confirm if the NX16 platform does not support sensors with resolutions lower than 32? Thank you very much.

Could you remove below code from the …/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c to verify.

And confirm the “Width/Height :” is correct by below command

v4l2-ctl --all

*height = clamp(*height, TEGRA_MIN_HEIGHT, TEGRA_MAX_HEIGHT);

Hi ShaneCCC:
I have removed the code as you mentioned, but after recompiling and booting the kernel, I encountered a “Kernel panic” error. Can you please advise if there are any other code changes that need to be made?

Hi ShaneCCC:
Additionally, I have configured the resolution in the device tree driver to be 2560x31, and the output of “media-ctl -p” also shows 2560x31. However, when I use the command “v4l2-ctl --all”, the resolution is still reported as 2560x32. The log is as follows:

[log content]
log.txt (5.0 KB)

Does looks like that modification would cause kernel panic.
BTW VI need 32 alignment that’s why v4l2-ctl always report 32 when less than 32.

Any reason need the height less than 32?

HI ShaneCCC:
Thank you for your reply. As we have customized a sensor with a resolution format of 2560x31 in RAW10, which only has 31 lines of data, I was wondering how to solve this issue.

Maybe output 1 dummy line make it as 32 and clamp it by user space APP.

HI ShaneCCC:
Thank you very much for your answer!
You mentioned that BTW VI requires 32 alignment, but for example, the resolution of 1920x1080 is not a multiple of 32 in the vertical dimension. I hope you can clarify my doubt.
Additionally, we just consulted the sensor chip supplier, and they explicitly stated that the resolution cannot be modified. In this case, even if we change the driver resolution to a size like 2560x32 or 2560x64, would the NX16 platform still be unable to receive MIPI data? I am eagerly awaiting your response.

If the sensor output size than report the cause failed that is expected.
For the 32 alignment, what I mean is min align to 32.

Suppose remove the clamp code should be help. But I only verify on r32 release only.


Thank you for your response. I have previously tried removing the clamp code, but if I only comment out that line of code, the kernel will generate a “Kernel panic” error. It seems that further modifications are required in other areas as well.

I just try on r35.4.1 without problem.
But I didn’t modify the sensor driver to report the height less than 32.

My version is 35.3.1, and I compiled the code after making modifications to generate the Image file. I replaced the original Image file on the development board with this one. Is there any issue with doing it this way?

Additionally, if the actual output resolution of my sensor has a vertical height less than 32, then the platform here will definitely not receive it, right? I would like to confirm this point.
Thank you very much!

I replace the /boot/Image for my modify.
Yes, if output less line VI will report short frame and abort.


In the trace.txt file that I uploaded initially, there is a field called CHANSEL_SHORT_FRAME, which indicates that the resolution is too small. It seems that the minimum row height restriction needs to be modified.
I will try to modify the code and set the minimum row height to 16.
Thank you very much.

HI ShaneCCC::
I have modified the minimum row height to 16 and replaced the Image file accordingly. However, when running the sensor, I encountered the following error. Could you please help me locate the issue?
Attached below are the modified strace information and log files:

trace.txt (393.7 KB)
log.txt (9.7 KB)