I have recently ported form L4T 32.5 to 35.1. I have a Ti IWR6843 connected through FPGA board. Everything is working fine with old BSP version. But with 35.1 I am seeing frame discarding issues. I have not done any changes everything is same as old version, only minor device tree changes.
This issue is very critical, at some time capture seems fine. Most of the times its failing. There is no consistency… Please help on resolving this issue.
Dmesg log:
[ +0.388101] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[ +0.225822] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[ +0.225059] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[ +0.088986] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: flags 2, err_data 0
[ +0.042756] [RCE] VM0 deactivating.VM0 activating.ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] “General error queue is out of sync with frame queue. ts=1578797785024 sof_ts=1579068182560 gerror_code=2 gerror_data=800062 notify_bits=40000”
[ +2.639956] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ +0.000283] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ +0.001008] (NULL device *): vi_capture_control_message: NULL VI channel received
[ +0.000210] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[ +0.000254] (NULL device *): vi_capture_control_message: NULL VI channel received
[ +0.000281] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
[ +0.000495] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
Trace log after boosting the clocks: trace_log.txt (742.2 KB)
it’s unsuccessful capture, VI driver reported warnings to requeue the buffer and dropping current frames.
you may see-also Camera Driver Porting section to review your driver since kernel version is now moving to 5.10 for Jetpack-5.
I have gone through the camera Porting document.
I have no changes to be done in VI or NVCSI level. My Radar device is connected over i2c and is very minimal driver. Everything is working well with 4.9 kernel and there were no much changes to be done in the driver level with 5.10 kernel except some minimal changes in the device tree. Some times the capture is proper but in some boots I am seeing this frame corruption issue. This will remain the same for every capture I do.
And also one more thing to add on, when I remove my kernel driver module first time I am seeing a crash in the dmesg. This is observed only when I rmmod for the first time and is not seen later.
Log: kernel_crash_rmmod.txt (3.9 KB)
Its just Raw ADC data we are capturing into .bin file using gstreamerr command. We are capturing for 2048X1024 resolution.
The same dts and kernel driver as kernel 4.9. The captured images has some valid data, but in between some frames are 0’s. Then again some valid data and 0’s.
is the frame rate output as expected from low-level driver?
please refer to Applications Using V4L2 IOCTL Directly by using V4L2 IOCTL to verify basic camera functionality.
the sample pipeline dump only 1 frame as raw file, you may revise stream-count to fetch the stream to examine the real frame-rate.
for example, $ 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 @JerryChang , My gstreamer command is :
gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=6 ! ‘video/x-bayer,format=bggr,width=2048,height=1024’ ! filesink location=/home/plato/Ms_Plato_RBB_V8.0/bin/app/…/…/imgFiles/image_20230628_1687937828.bin &. But if I modify the v4l2 command accordingly gives “The pixelformat ‘BGGR16’ is invalid”. and tried with RG10 & RG16 both gives invalid format.
Also, gave a try with - v4l2-ctl -d /dev/video1 --set-fmt-video=width=2048,height=1024,pixelformat=BYR2 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100. Does not display anything, waited for sometime and closed ctrl+c.
Can you provide a proper command to run using v4l2 util.
here’re failures.
it’s discarding frame error report by VI, capture engine is in error and it must reset.
tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: flags 2, err_data 0
[RCE] ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] "General error queue is out of sync with frame queue. ts=96360432320 sof_ts=96360559808 gerror_code=2 gerror_data=800062 notify_bits=40000"
tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
(NULL device *): vi_capture_control_message: NULL VI channel received
t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
(NULL device *): vi_capture_control_message: NULL VI channel received
t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
BTW,
JetPack-5.0.2 / l4t-r35.1 isn’t quite stable, and we’ve revise several camera bugs.
is it possible for moving to the latest Jetpack release version, such as JP-5.1.1/l4t-r35.3.1 for confirmation?
Recently we have moved from 32.5 to 35.2.1 L4T. So it will be very difficult to move again to 35.3.1 as of now. I will check. But from the dmesg log can you point out what could have gone wrong? Anything suspicious?
Yes I have already ported the GPIO’s. GPIo mappings have been changed from 4.9 to 5.10.
Sometimes I am able to capture properly, but most of the times seeing this issue. But if it exists then it will always show up.
may I know what’s the scenarios between these success/failure captures?
please see-also Topic 253615, it’s also report the issue with FPGA device that can only capture frames occasionally.
is it possible to program a software reset, or toggle power-supply before capture the frames.