Understanding vi error messages.

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

We are implementing a multi-channel composite video capture board, with 4 CSI
inputs to a TX2 module. We are to the point where we believe we have properly
formatted CSI data being fed into the CSI inputs, and on the kernel/dtb side
we have a driver modeled on the ov5693 driver that seems to integrate properly
with the media control layer (media-ctl -p looks correct) and the v4l2 driver
(we have /dev/video0 - /dev/video3).

We are testing with v4l2-ctl

v4l2-ctl -d /dev/video0 --stream-mmap --stream-count 10 --stream-to frames.raw

The kernel seems to be configuring the CSI interface and the VI interface for
the data stream. The only problem is no video frames are captured.

Every time we end up with timeouts:

3594.091001] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11

Occasionally there are specific vi error messages, currently error 7:

[  103.727862] tegra-vi4 15700000.vi: Status:  7 channel:00 frame:0000
[  103.727865] tegra-vi4 15700000.vi:          timestamp sof 113356046112 eof 113372091744 data 0x00000001
[  103.727867] tegra-vi4 15700000.vi:          capture_id 16 stream  0 vchan  0

Based on what I can see in rtcpu/vi-notify.h, this is a CHANSEL_SHORT_FRAME error.

We have adjusted the line_length in the device tree but it hasn’t changed anything.

Is there a good way to figure out why the video data isn’t getting transferred? I’ve
printed out the csi and vi register configuration steps if that would help.

Has anyone else run into problems like this?

Thanks in advance,

Cary

#2

hello cobrien,

did your “video capture board” able to generate test pattern for testing?
please running with test pattern to narrow down the issue. thanks

#3

@cobrien
CHANSEL_SHORT_FRAME is the output active_h didn’t as expect. Make the the output size to modify the height in the kernel driver and active_h in DT.

#4

Jerry, yes we can run a test pattern or captured video.
Note we have a digital (BT.656) loopback in the FPGA and a D/A output so
we can monitor the captured video at that level. I tried with the test pattern
and still get the Status 7 error from the vi subsystem.

Shane, this is a composite video in, so the video is interlaced, so each frame
has half the resolution. Checking… Changing to 240 didn’t seem to help. same error 7.

I actually reduced the active_h to 140 and still it returns error 7 which I believe is
CHANSEL_SHORT_FRAME.

It does seems as if reducing the active_w below 720 changes the error message so that
in vi4_fops.c:tegra_channel_notify_status_callback none of the ports are valid??.

#5

Jerry, yes we can run a test pattern or captured video.
Note we have a digital (BT.656) loopback in the FPGA and a D/A output so
we can monitor the captured video at that level. I tried with the test pattern
and still get the Status 7 error from the vi subsystem.

Shane, this is a composite video in, so the video is interlaced, so each frame
has half the resolution. Checking… Changing to 240 didn’t seem to help. same error 7.

I actually reduced the active_h to 140 and still it returns error 7 which I believe is
CHANSEL_SHORT_FRAME.

It does seems as if reducing the active_w below 720 changes the error message so that
in vi4_fops.c:tegra_channel_notify_status_callback none of the ports are valid??.

#6

I spent time going over the errors we got from different resolutions trying
to understand what is going on. The input is 720x480 interlaced, so each
frame is 720x240.

Depending on the mumber of lines, from the vi system I get either a Status 7 (short frame) or
a Status 4 (error). In the Parker TRM section 27.7.1 it talks about ‘notifications’ from
the RTCPU handling the transfer (?). Status 7 seems to be SHORT_FRAME, which makes sense,
If I set the vertical resolution for more than 254 I get status 7, short frame. If I set
the vertical resolution for 254 or less I get Status 4, FAULT which is less clear.

From the TRM it seems as if there are additional error flags for the FAULT status,
things like overrun or underrun in a line, or incompatible format, but it is unclear how
this information could be extracted.

Unfortunately there was no vertical resolution setting that would transfer data.

Is there any way to get the additional status information that could explain what
the fault is?

Thanks in Advance,
Cary

#7

@cobrien
Would you try to disable the interlace. Suppose interlace mode are not support.

#8

The colorbar generator from the CSI converter is non-interlaced, we are
able to frame-capture that. The problem that the video source is an interlaced
ntsc composite camera. De-interlacting outside of the TX2 would require a hardware
change. If we could capture the fields we could possibly deinterlace in gstreamer.

I did find that dmesg sometimes shows

nvcsi 150c0000.nvcsi: csi4_stream_check_status (0) INTR_STATUS 0x00000008
nvcsi 150c0000.nvcsi: csi4_stream_check_status (0) ERR_INTR_STATUS 0x00000008

Which according to the Parker TRM Section 28.6.63 is intr_stat_pd_wc_short_err_vc0
I.e a short line or frame? There isn’t much detail about the error.

#9

@cobrien
The only way to for your case is check if CSI converter can De-interlacing then output to TX2.