CSI Camera 0 Hangs When Trying to Collect an Image with v4l2-ctl

Autonomous Machines Jetson & Embedded Systems Jetson Orin Nano
1

We’re trying to move to Orin Nano and Orin NX from Xavier NX and the CSI cameras that work fine with Xavier NX does not work with the Orins. We’re currently using Orin Nano Dev Kit (from Seeed Studio), Orin NX 8GB module on an A603 carrier board (from Seeed), and a Xavier NX module on an A203 carrier board (from Seeed).

To simplify the comparison of the working system (Xavier NX) with the two non-working systems (Orin Nano and Orin NX), we’ve installed jetpack 5.1.1 (rev 1) on each system from scratch using sdkmanager, then installed v4l-utils (sudo apt install v4l-utils), and then run v4l2-ctl commands.

v4l2-ctl --list-devices

The output for the Xavier NX is:

NVIDIA Tegra Video Input Device (platform:tegra-camrtc-ca):
    /dev/media0
vi-output, imx219 9-0010 (platform:tegra-capture-vi:0):
    /dev/video0

The output for both the Orins is:

NVIDIA Tegra Video Input Device (platform:tegra-camrtc-ca):
     /dev/media0
vi-output, imx219 9-0010 (platform:tegra-capture-vi:1):
     /dev/video0

v4l2-ctl -d /dev/video0 --stream-count=1 --stream-mmap --stream-to=frame.raw --verbose


The output to stdout/stderr starts the same for all 3 devices:

VIDIOC_QUERYCAP: ok
       VIDIOC_REQBUFS returned 0 (Success)
       VIDIOC_QUERYBUF returned 0 (Success)
       VIDIOC_QUERYBUF returned 0 (Success)
       VIDIOC_QUERYBUF returned 0 (Success)
       VIDIOC_QUERYBUF returned 0 (Success)
       VIDIOC_QBUF returned 0 (Success)
       VIDIOC_QBUF returned 0 (Success)
       VIDIOC_QBUF returned 0 (Success)
       VIDIOC_QBUF returned 0 (Success)
       VIDIOC_STREAMON returned 0 (Success)



However, at this point the behavior of the Xavier and the Orins diverges. On the Xavier the final stdout/stderr output is:


cap dqbuf: 0 seq:      0 bytesused: 16163840 ts: 2880.964110 (ts-monotonic, ts-src-eof)



and it writes out a single image to frame.raw.


On the Orins, no image is written and the output to stdout/stderr repeats the following 5 lines forever:


cap dqbuf: 0 seq:      0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)



On the Orin Nano Development Kit there are 2 CSI connectors and if the camera is plugged in to the 2nd connector then it works correctly and similarly to the Xavier NX. However, on both Orins the camera does not work (per the behavior described above) if the camera is plugged into the 1st connector (and the Orin NX has only 1 CSI connector).


How can get the camera to work when connected to the 1st (and often only CSI connector)?


P.S. A saw suggestions to use /opt/nvidia/jetson-io/jetson-io.py. I did this and it didn’t help.
3

What the sensor connector to? Did you try another connector?

4

I’ve tried numerous IMX219 cameras all with the same result. The primary one that we’re trying to use is Arducam B0394 with the following amazon link:

The specific cable used for the Orin NX is just what came with the various cameras. The specific cable used with the Orin Nano Dev Kit is the following amazon link:

Remember, all cameras and cables work perfectly with Xavier NX and the above cables work fine for the CAM1 connector on the Orin Nano Dev Kit, but they DON’T WORK on CAM0 on the Orin Nano Dev Kit, nor do they work on the only available CSI connector on the Orin NX.

5

Please update to latest release r35.4.1 to check.

Thanks

6

I upgraded to r35.4.1 on Orin Nano Dev Kit and Orin Nx. The results are the same as above (no camera data on Orin NX or Orin Nano Dev Kit CAM0 connector but data collected on CAM1 connector).

I saw the following topic earlier that seems sorta related but I can’t figure out how and I’m hoping that stock NVidia software would work without me having to build kernels from scratch:

7

Did you try configure by jetson-io?

8

Yes. Using jetson-io didn’t help (it didn’t make any difference at all).

9

Here’s my test.

nvidia@tegra-ubuntu:~$ v4l2-ctl --all
Driver Info:
        Driver name      : tegra-video
        Card type        : vi-output, imx219 9-0010
        Bus info         : platform:tegra-capture-vi:1
        Driver version   : 5.10.120
        Capabilities     : 0x84200001
                Video Capture
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04200001
                Video Capture
                Streaming
                Extended Pix Format
Media Driver Info:
        Driver name      : tegra-camrtc-ca
        Model            : NVIDIA Tegra Video Input Device
        Serial           :
        Bus info         :
        Media version    : 5.10.120
        Hardware revision: 0x00000003 (3)
        Driver version   : 5.10.120
Interface Info:
        ID               : 0x0300000b
        Type             : V4L Video
Entity Info:
        ID               : 0x00000009 (9)
        Name             : vi-output, imx219 9-0010
        Function         : V4L2 I/O
        Pad 0x0100000a   : 0: Sink
          Link 0x0200000f: from remote pad 0x1000003 of entity '13e40000.host1x:nvcsi@15a00000-': Data, Enabled
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
        Width/Height      : 3280/2464
        Pixel Format      : 'RG10' (10-bit Bayer RGRG/GBGB)
        Field             : None
        Bytes per Line    : 6560
        Size Image        : 16163840
        Colorspace        : sRGB
        Transfer Function : Default (maps to sRGB)
        YCbCr/HSV Encoding: Default (maps to ITU-R 601)
        Quantization      : Default (maps to Full Range)
        Flags             :

Camera Controls

                     group_hold 0x009a2003 (bool)   : default=0 value=0 flags=execute-on-write
                    sensor_mode 0x009a2008 (int64)  : min=0 max=5 step=1 default=0 value=0 flags=slider
                           gain 0x009a2009 (int64)  : min=15 max=170 step=1 default=16 value=15 flags=slider
                       exposure 0x009a200a (int64)  : min=12 max=683709 step=1 default=2495 value=12 flags=slider
                     frame_rate 0x009a200b (int64)  : min=2000000 max=21000000 step=1 default=21000000 value=2000000 flags=slider
           sensor_configuration 0x009a2032 (u32)    : min=0 max=4294967295 step=1 default=0 [22] flags=read-only, volatile, has-payload
         sensor_mode_i2c_packet 0x009a2033 (u32)    : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
      sensor_control_i2c_packet 0x009a2034 (u32)    : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
                    bypass_mode 0x009a2064 (intmenu): min=0 max=1 default=0 value=0
                                0: 0 (0x0)
                                1: 1 (0x1)
                override_enable 0x009a2065 (intmenu): min=0 max=1 default=0 value=0
                                0: 0 (0x0)
                                1: 1 (0x1)
                   height_align 0x009a2066 (int)    : min=1 max=16 step=1 default=1 value=1
                     size_align 0x009a2067 (intmenu): min=0 max=2 default=0 value=0
                                0: 1 (0x1)
                                1: 65536 (0x10000)
                                2: 131072 (0x20000)
               write_isp_format 0x009a2068 (int)    : min=1 max=1 step=1 default=1 value=1
       sensor_signal_properties 0x009a2069 (u32)    : min=0 max=4294967295 step=1 default=0 [30][18] flags=read-only, has-payload
        sensor_image_properties 0x009a206a (u32)    : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
      sensor_control_properties 0x009a206b (u32)    : min=0 max=4294967295 step=1 default=0 [30][36] flags=read-only, has-payload
              sensor_dv_timings 0x009a206c (u32)    : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
               low_latency_mode 0x009a206d (bool)   : default=0 value=0
               preferred_stride 0x009a206e (int)    : min=0 max=65535 step=1 default=0 value=0
                   sensor_modes 0x009a2082 (int)    : min=0 max=30 step=1 default=30 value=5 flags=read-only
nvidia@tegra-ubuntu:~$ v4l2-ctl -d /dev/video0 --stream-count=1 --stream-mmap --stream-to=frame.raw --verbose
VIDIOC_QUERYCAP: ok
                VIDIOC_REQBUFS returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq:      0 bytesused: 16163840 ts: 8614.548568 (ts-monotonic, ts-src-eof)
10

I just typed in the same 2 commands and got the exact same output for the first command. The 2nd command’s output is identical EXCEPT your last line is replaced by the following 5 lines repeated forever:

cap dqbuf: 0 seq:      0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      0 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 16163840 ts: 0.000000 (error, ts-monotonic, ts-src-eof)

Note again, that if I plug the camera into CAM1, I get the same output you do. So it seems to me that the camera and cable are probably good. Especially since I have a bunch of camera and a bunch of cables and the results are the same for all of them.

Also please note that these cameras work fine with Xavier NXs.

Any ideas?

11

Check the lane_polarity.

sudo cat /proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10/mode0/lane_polarity
12

Output is: 6

13

The value is correct. Could you check the dmesg if any error after v4l2-ctl command.

14

There seem to be errors:

< [24739.054571] bwmgr API not supported
< [33221.608058] bwmgr API not supported
< [33224.145680] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
< [33224.158411] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
< [33224.168859] (NULL device *): vi_capture_control_message: NULL VI channel received
< [33224.176579] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=1, csi_port=1
< [33224.187247] (NULL device *): vi_capture_control_message: NULL VI channel received
< [33224.194955] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 1 vc- 0
< [33224.205729] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
< [33226.737418] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
< [33226.746560] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
< [33226.756501] (NULL device *): vi_capture_control_message: NULL VI channel received
< [33226.764219] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=1, csi_port=1
< [33226.774889] (NULL device *): vi_capture_control_message: NULL VI channel received
< [33226.782608] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 1 vc- 0
< [33226.793652] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel

What does it mean and how do I fix it?

1 Like
15

This message tell didn’t receive data from sensor.
Any imx219 i2c error message?

16 
sudo dmesg | grep -i imx219
[ 12.400448] **imx219** 9-0010: tegracam sensor driver:**imx219**_v2.0.6
[ 12.450486] tegra-camrtc-capture-vi tegra-capture-vi: subdev **imx219** 9-0010 bound
[ 12.463592] **imx219** 10-0010: tegracam sensor driver:**imx219**_v2.0.6
[ 12.474360] **imx219** 10-0010: **imx219**_board_setup: error during i2c read probe (-121)
[ 12.491018] **imx219** 10-0010: board setup failed
[ 12.495938] **imx219**: probe of 10-0010 failed with error -121

But these errors happen near boot and the errors are for 10-0010 which isn’t connected. No errors after v4l2-ctl command.

17

Can you let me know the exact model of the camera you are testing with?

18

Looks like there’s no any i2c error for 9-0010 of imx219.
Looks like it could be HW problem on this Orin Nano CAM0 due to there’s no problem on CAM1. I would suggest send it to RMA

19

OK. But you think our Orin NX (8 GB) which exhibits the same non-working behavior also happens to just be bad hardware?

20

Also, please tell me what camera you are using.

21

WoW, that’s weird if Orin NX got the same problem.
I need to check which module of imx219 for my test to update it later.

1 Like