CSI camera capture crash causes "vi capture dequeue status failed"

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
#1

I’m trying to capture an image with the following setup:

  • csi 4 lane ar0231 sensor
  • GMSL2 SerDes to CSI-2 interface
  • Xavier running r31.1 release
  • have camera continually sending pattern data that I confirm is being sent via scope
  • raw 12 bayer pattern GRBG
  • sudo v4l2-compliance -d /dev/video0
    compliance test passes
  • trying to capture single image with command:

v4l2-ctl -d /dev/video0 -w --verbose --set-fmt-video=width=1928,height=1208,pixelformat=BA12 --set-ctrl=sensor_mode=0 --stream-mmap --stream-count=1 --set-ctrl bypass_mode=0 --stream-to=ar0231.raw

I get the following errors below. I can actually get the v4l2-ctl call to return and put data into a file if I run the following command first:

sudo sh -c ‘echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked’

That command appears to be critical but I don’t know why. What is it doing? and do I really need to be setting that? or must I have some other setting wrong? I can’t find any documentation about this.

Here is the error case:

nvidia@jetson-0423518031491:~$ [ 117.486751] tegra194-vi5 15c10000.vi: vi capture dequeue status failed
[ 117.518732] tegra194-vi5 15c10000.vi: vi capture dequeue status failed
[ 117.550587] tegra194-vi5 15c10000.vi: vi capture dequeue status failed
[ 117.568837] tegra194-vi5 15c10000.vi: channel error, resetting the channel
[ 117.582546] tegra194-vi5 15c10000.vi: vi capture dequeue status failed
[ 117.582972] tegra194-vi5 15c10000.vi: channel error, resetting the channel
[ 117.614522] tegra194-vi5 15c10000.vi: vi capture dequeue status failed
[ 117.615341] tegra194-vi5 15c10000.vi: channel error, resetting the channel
[ 117.646449] tegra194-vi5 15c10000.vi: vi capture dequeue status failed
[ 117.646720] ------------[ cut here ]------------
[ 117.646826] WARNING: CPU: 3 PID: 7927 at /home/kurt/pro/nvidia/L4T_R31.1/kernel/kernel-4.9/drivers/media/v4l2-core/videobuf2-core.c:899 vb2_buffer_done+0x1f0/0x230
[ 117.647028] tegra194-vi5 15c10000.vi: channel error, resetting the channel
[ 117.647491] —[ end trace 13f1b1ecd6fdc2e7 ]—
[ 117.678374] tegra194-vi5 15c10000.vi: vi capture dequeue status failed

[ 117.646720] ------------[ cut here ]------------
[ 117.646826] WARNING: CPU: 3 PID: 7927 at /home/kurt/pro/nvidia/L4T_R31.1/kernel/kernel-4.9/drivers/media/v4l2-core/videobuf2-core.c:899 vb2_buffer_done+0x1f0/0x230
[ 117.647028] tegra194-vi5 15c10000.vi: channel error, resetting the channel
[ 117.647197] Modules linked in: bnep fuse nvs_bmi160 nvs bluedroid_pm ip_tables x_tables

[ 117.647249] CPU: 3 PID: 7927 Comm: vi-output, mtc_ Not tainted 4.9.108 #37
[ 117.647252] Hardware name: jetson-xavier (DT)
[ 117.647255] task: ffffffc3e9892a00 task.stack: ffffffc3563e4000
[ 117.647261] PC is at vb2_buffer_done+0x1f0/0x230
[ 117.647266] LR is at free_ring_buffers+0x6c/0x140
[ 117.647281] pc : [] lr : [] pstate: 20c00045
[ 117.647287] sp : ffffffc3563e7d00
[ 117.647300] x29: ffffffc3563e7d00 x28: 0000000000000000
[ 117.647316] x27: 0000000000000000 x26: ffffffc3d614aeb8
[ 117.647328] x25: ffffff800da3e000 x24: 431bde82d7b634db
[ 117.647340] x23: 0000000000000007 x22: ffffffc3d614ab48
[ 117.647353] x21: ffffffc3e817f400 x20: ffffffc3e817f400
[ 117.647364] x19: ffffffc3d614a018 x18: 000000000012650b
[ 117.647377] x17: 0000007f9bc85748 x16: 00000000000000b7
[ 117.647411] x15: 0000000000000000 x14: 00000000000000ea
[ 117.647415] x13: 0000000000000000 x12: 0000000000000092
[ 117.647420] x11: 00000000000c0e73 x10: 0000000000000000
[ 117.647427] x9 : 0000000000000400 x8 : 000000000000021a
[ 117.647431] x7 : 0000000000000000 x6 : 000000000000009b
[ 117.647437] x5 : 0000000000000004 x4 : 0000000000000007
[ 117.647441] x3 : 0000000000000003 x2 : ffffffc3ada19118
[ 117.647483] x1 : 0000000000000007 x0 : 0000000000000007

clocks.txt (29.1 KB)
daisy.dts.txt (264 KB)

#2

After executing this:

sudo sh -c ‘echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked’

nvidia@jetson-0423518031491:~/dev/tools$ v4l2-ctl -d /dev/video0 -w --verbose --set-fmt-video=width=1928,height=1208,pixelformat=BA12 --set-ctrl=sensor_mode=0 --stream-mmap --stream-count=1 --set-ctrl bypass_mode=0 --stream-to=ar0231.raw
Opening in BLOCKING MODE
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
Width/Height : 1928/1208
Pixel Format : ‘BA12’
Field : None
Bytes per Line : 3856
Size Image : 4658048
Colorspace : sRGB
Transfer Function : Default (maps to sRGB)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Full Range)
Flags :
VIDIOC_REQBUFS: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_STREAMON: ok
Index : 0
Type : Video Capture
Flags : mapped
Field : None
Sequence : 0
Length : 4658048
Bytesused: 4658048
Timestamp: 0.000000s (Monotonic, End-of-Frame)

VIDIOC_STREAMOFF: ok

#3

Please add “serdes_pix_clk_hz” to your sensor mode in DT, and have the value bigger than pix_clk_hz.

serdes_pix_clk_hz:
Specifies the output clock rate for the Serializer/Deserializer (GMSL or FPD Link).
Only needed for camera modules that use SerDes.
For more information, see SerDes Pixel Clock.

#4

ShaneCCC,

Kurt is running L4T 31.1. serdes_pix_clk_hz appears to be only relevant for L4T 32.1. At least, a search through the 31.1 source tree for “serdes_pix_clk_hz” turns up nothing for me.

–tim

#5

serdes_pix_clk_hz was added to R32.1 and is not present in R31.1. If at all possible I highly recommend switching to R32.1.

If you must use R31.1 then be sure to configure pix_clk_hz not to match the pixel clock of the ar0231 but to that of the CSI rate coming out of your deserializer. If you don’t do this then the various clocks in the system won’t be configured at the right speed and can easily result in no frames being received and other issues. Also be careful that you compute exposure time correctly since that computation will need to use the pixel clock of the sensor and not that of the deserializer.

Check that your CSI lane counts match that of the deserializer and not the image sensor.

I recommend maxing out the clocks at least until you start getting frames from the sensor.

#6

@D3_growe,

Thanks! That was a big help! We updated our DT to use the CSI rate for pix_clk_hz and it’s now able to capture without the mrq_rate_locked workaround AND it has been capturing individual frames without crashing.

–tim

#7

Tim,

That’s awesome news! Internet high-five! I’m glad I could help.

I already have an ar0231 driver and GMSL2 drivers but I was wondering if you are at liberty to share your source code? I’m always up for the opportunity to learn new techniques and maybe you’ve implemented a feature I haven’t!

Thanks,
Greg

#8

Greg,

Driver development is still undergoing. Kurt has been doing the driver development so I’ll leave it up to him to determine if it’s something he can share.

Thanks again for the assistance.

–tim

#9