Tegra V4L2 Driver Discards Valid Frames (err_data 512)

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
,
1

Hello,

I developed a custom device driver on the Xavier NX, and the V4L2 interface for this device is designed to support only 1280x720 at 60fps in GRAY8 format.

v4l2-ctl --list-formats-ext -d /dev/video0
ioctl: VIDIOC_ENUM_FMT
    Type: Video Capture

    [0]: 'GREY' (8-bit Greyscale)
        Size: Discrete 1280x720
                Interval: Discrete 0.017s (60.000 fps)

I want to receive data from the camera and process it using GStreamer.

v4l2-ctl -d /dev/video0  --stream-mmap --stream-count=200 --stream-to=/dev/null --verbose

When I run the above command, I get the following result.

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: 921600 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 921600 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 921600 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 921600 ts: 0.000000 (error, ts-monotonic, ts-src-eof)

After the last line of the output above, no further logs appear, no matter how long I wait.

Therefore, when I check the Tegra logs using the following command:

sudo dmesg | grep -i -e vi -e nvcsi -e csi -e imx -e tegra -e camera

I get this output:

[601749.270099] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[601749.286946] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 2, flags: 0, err_data 512
[601749.303607] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 3, flags: 0, err_data 512
[601749.320155] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 4, flags: 0, err_data 512

Questions:

  1. If you have any knowledge about the meaning of the err_data 512 error code, please share it.

  2. As you can see from the bytesused field, the frame size seems to be correct, so why is this error occurring?

Any insights would be greatly appreciated. Thank you in advance!

3

Get the trace log to check.

https://elinux.org/Jetson/l4t/Camera_BringUp

4

Hello, ShaneCCC
I executed the following commands to manually start the Argus daemon with debug logging:

sudo service nvargus-daemon stop
sudo su
export enableCamPclLogs=5
export enableCamScfLogs=5
/usr/sbin/nvargus-daemon

The output was:

=== NVIDIA Libargus Camera Service (0.99.33)=== Listening for connections...

Then, from another terminal, I ran the following command:

v4l2-ctl -d /dev/video0  --stream-mmap --stream-count=200 --stream-to=/dev/null --verbose

However, even after running the v4l2-ctl command, there was no further output from the Argus daemon beyond “Listening for connections…”.
Previously, the v4l2-ctl command would only output 4 frames and then stop. However, after restarting the nvargus-daemon manually with debug logging enabled, I noticed a change in behavior.

v4l2-ctl -d /dev/video0  --stream-mmap --stream-count=200 --stream-to=/dev/null --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: 921600 ts: 679647.738931 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 921600 ts: 679647.755566 delta: 16.635 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 921600 ts: 679647.772201 delta: 16.635 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 921600 ts: 679647.788836 delta: 16.635 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      4 bytesused: 921600 ts: 679647.805471 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      5 bytesused: 921600 ts: 679647.822106 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      6 bytesused: 921600 ts: 679647.838741 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      7 bytesused: 921600 ts: 679647.855376 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      8 bytesused: 921600 ts: 679647.872011 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      9 bytesused: 921600 ts: 679647.888646 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:     10 bytesused: 921600 ts: 679647.905281 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:     11 bytesused: 921600 ts: 679647.921915 delta: 16.634 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:     12 bytesused: 921600 ts: 679647.938550 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:     13 bytesused: 921600 ts: 679647.955185 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:     14 bytesused: 921600 ts: 679647.971820 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:     15 bytesused: 921600 ts: 679647.988455 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:     16 bytesused: 921600 ts: 679648.005090 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:     17 bytesused: 921600 ts: 679648.021725 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:     18 bytesused: 921600 ts: 679648.038360 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:     19 bytesused: 921600 ts: 679648.054995 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:     20 bytesused: 921600 ts: 679648.071630 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)

However, despite the fact that v4l2-ctl is now reporting valid timestamps and continuous frame streaming, the kernel log still shows the following persistent errors:

dmesg -wH | grep tegra
[  +3.376732] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[  +0.016847] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 2, flags: 0, err_data 512
[  +0.016661] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 3, flags: 0, err_data 512
[  +0.016548] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 4, flags: 0, err_data 512
[Aug18 16:36] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[  +0.016782] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 2, flags: 0, err_data 512
[  +0.016628] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 3, flags: 0, err_data 512
[  +0.016470] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 4, flags: 0, err_data 512
[Aug18 16:37] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[  +0.016425] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 2, flags: 0, err_data 512
[  +0.016462] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 3, flags: 0, err_data 512
[  +0.016785] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 4, flags: 0, err_data 512
[Aug18 16:40] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
[  +0.016808] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 2, flags: 0, err_data 512
[ +15.610730] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 512
5

Boost the clocks to try.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
6

Hello, ShaneCCC
After running the following commands:

root@ubuntu:/home/eslab# echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
root@ubuntu:/home/eslab# echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
root@ubuntu:/home/eslab# echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
root@ubuntu:/home/eslab# echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
root@ubuntu:/home/eslab# cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
460800000
root@ubuntu:/home/eslab# cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
576000000
root@ubuntu:/home/eslab# cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
314000000
root@ubuntu:/home/eslab# cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
1866000000

the frame capture behavior improved significantly.
I was able to successfully stream and capture all 200 frames via v4l2-ctl, with valid timestamps and stable 60.11 fps:

...
cap dqbuf: 1 seq:    193 bytesused: 921600 ts: 1684.792275 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:    194 bytesused: 921600 ts: 1684.808911 delta: 16.636 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:    195 bytesused: 921600 ts: 1684.825546 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:    196 bytesused: 921600 ts: 1684.842181 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:    197 bytesused: 921600 ts: 1684.858816 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:    198 bytesused: 921600 ts: 1684.875451 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:    199 bytesused: 921600 ts: 1684.892086 delta: 16.635 ms fps: 60.11 (ts-monotonic, ts-src-eof)

It appears that the issue has been resolved.
Could anyone explain why this fixed the problem? I appreciate your help!

7

It could be improper pix_clk_hz to allocate less bandwidth cause the problem.

You may need to review and adjust the pix_clk_hz to confirm. You can check the programing guide to get the detail.

1 Like
9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.