The CRC error occurs when nvarguscamerasrc is used

Hello,

It’s fine when v4l2-ctrl is used(raw image) but the MIPI CRC error frequently occurs when nvarguscamerasrc is used with gstreamer.
After booting, the first streaming with nvarguscamerasrc is always fine.
If a CRC error occurs at least once, a CRC error will continue to occur from the next time until v4l2-ctl is used with a large number of ‘stream-count’.
If I use a different resolution and MIPI rate, the CRC error does not occur.
It is the same when I try to physically power on/off the sensor.

I think this relates Jetson setup , not a sensor configuration.

booting → nvarguscamerasrc(always good) → … → nvarguscamerasrc(crc error) → nvarguscamerasrc (always crc error) →
physically power on/off sensor → nvarguscamerasrc (always crc error) → v4l2-ctl (–stream-count=300) → nvarguscamerasrc(good) → … → nvarguscamerasrc(crc error)

MIPI Setting
MIPI rate: 887Msps
MIPI CPHY 3 lanes

v4l2-ctl -d /dev/video0 --set-fmt-video=width=3840,height=2160,pixelformat=RG10 \
--set-ctrl bypass_mode=0,sensor_mode=0 --stream-mmap --stream-count=300  --verbose
gst-launch-1.0 -v --gst-debug-level=3 nvarguscamerasrc sensor-id=0 ! \
capsfilter caps="video/x-raw(memory:NVMM), width=(int)3840, height=(int)2160, format=(string)NV12, framerate=(fraction)30/1" ! queue ! nv3dsink

crc trace log

     kworker/2:0-25      [002] ....  1786.217755: rtcpu_vinotify_event: tstamp:56567995695 cch:1 vi:0 tag:FS channel:0x00 frame:3 vi_tstamp:1810165235104 data:0x0000000300000010
     kworker/2:0-25      [002] ....  1786.217755: rtcpu_vinotify_event: tstamp:56567995830 cch:1 vi:0 tag:ATOMP_FS channel:0x00 frame:3 vi_tstamp:1810165235136 data:0x0000000000000800
     kworker/2:0-25      [002] ....  1786.217756: rtcpu_vinotify_event: tstamp:56567995981 cch:1 vi:0 tag:CHANSEL_EMBED_SOF channel:0x0b frame:3 vi_tstamp:1810165236128 data:0x0000000000000004
     kworker/2:0-25      [002] ....  1786.217756: rtcpu_vinotify_event: tstamp:56567996111 cch:1 vi:0 tag:CHANSEL_EMBED_EOF channel:0x0b frame:3 vi_tstamp:1810165249696 data:0x0000000000010008
     kworker/2:0-25      [002] ....  1786.217756: rtcpu_vinotify_event: tstamp:56567996260 cch:1 vi:0 tag:ATOMP_EMB_DATA_DONE channel:0x0b frame:3 vi_tstamp:1810165250336 data:0x0000000000000000
     kworker/2:0-25      [002] ....  1786.217757: rtcpu_vinotify_event: tstamp:56567996392 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:3 vi_tstamp:1810165256992 data:0x0000000003020001
     kworker/2:0-25      [002] ....  1786.217757: rtcpu_vinotify_event: tstamp:56567996543 cch:1 vi:0 tag:CHANSEL_PXL_SOF channel:0x0b frame:3 vi_tstamp:1810165561600 data:0x0000000000000001
     kworker/2:0-25      [002] ....  1786.217758: rtcpu_vinotify_event: tstamp:56567996671 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:3 vi_tstamp:1810165565408 data:0x0000000008020001
     kworker/2:0-25      [002] ....  1786.217758: rtcpu_vinotify_event: tstamp:56567996819 cch:1 vi:0 tag:ATOMP_FRAME_NLINES_DONE channel:0x0b frame:3 vi_tstamp:1810169588512 data:0x0000000000000000
     kworker/2:0-25      [002] ....  1786.217758: rtcpu_vinotify_event: tstamp:56567996949 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:3 vi_tstamp:1810169592096 data:0x0000000002020001
     kworker/2:0-25      [002] ....  1786.217759: rtcpu_vinotify_event: tstamp:56567997098 cch:1 vi:0 tag:ATOMP_FRAME_NLINES_DONE channel:0x0b frame:3 vi_tstamp:1810173616064 data:0x0000000000000000
     kworker/2:0-25      [002] ....  1786.217759: rtcpu_vinotify_event: tstamp:56567997230 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:3 vi_tstamp:1810173619616 data:0x0000000002020001
     kworker/2:0-25      [002] ....  1786.217760: rtcpu_vinotify_event: tstamp:56568052836 cch:1 vi:0 tag:ATOMP_FRAME_NLINES_DONE channel:0x0b frame:3 vi_tstamp:1810177643520 data:0x0000000000000000
     kworker/2:0-25      [002] ....  1786.217760: rtcpu_vinotify_event: tstamp:56568052969 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:3 vi_tstamp:1810177647072 data:0x0000000002020001
     kworker/2:0-25      [002] ....  1786.217760: rtcpu_nvcsi_intr: tstamp:56568089617 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:0-25      [002] ....  1786.217761: rtcpu_nvcsi_intr: tstamp:56568089617 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:0-25      [002] ....  1786.217762: rtcpu_vinotify_error: tstamp:56568180058 cch:1 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:3 vi_tstamp:1810181671264 data:0x0000000300400060
     kworker/2:0-25      [002] ....  1786.273735: rtcpu_vinotify_event: tstamp:56568409156 cch:1 vi:0 tag:CHANSEL_PXL_EOF channel:0x0b frame:3 vi_tstamp:1810181670240 data:0x00000000086f0002
     kworker/2:0-25      [002] ....  1786.273738: rtcpu_vinotify_event: tstamp:56568409290 cch:1 vi:0 tag:ATOMP_FRAME_DONE channel:0x0b frame:3 vi_tstamp:1810181670880 data:0x0000000000000000
     kworker/2:0-25      [002] ....  1786.273738: rtcpu_vinotify_event: tstamp:56568409442 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:3 vi_tstamp:1810181678688 data:0x0000000002020001
     kworker/2:0-25      [002] ....  1786.273738: rtcpu_vinotify_event: tstamp:56568409585 cch:1 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:3 vi_tstamp:1810181671264 data:0x0000000300400060
     kworker/2:0-25      [002] ....  1786.273738: rtcpu_vinotify_event: tstamp:56568409739 cch:1 vi:0 tag:ATOMP_FE channel:0x00 frame:3 vi_tstamp:1810181671296 data:0x0000000000000800
     kworker/2:0-25      [002] ....  1786.273738: rtcpu_vinotify_event: tstamp:56568409870 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:3 vi_tstamp:1810181693184 data:0x0000000000020001
     kworker/2:0-25      [002] ....  1786.273739: rtcpu_vinotify_event: tstamp:56568410020 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x0b frame:0 vi_tstamp:1810188037408 data:0x359cc50010000000
     kworker/2:0-25      [002] ....  1786.273739: rtcpu_vinotify_event: tstamp:56568410150 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x0b frame:0 vi_tstamp:1810188053568 data:0x0000000031000002
     kworker/2:0-25      [002] ....  1786.273739: rtcpu_vinotify_event: tstamp:56568707370 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x0b frame:0 vi_tstamp:1810190166144 data:0x359cc80010000000
     kworker/2:0-25      [002] ....  1786.273739: rtcpu_vinotify_event: tstamp:56568707502 cch:1 vi:0 tag:VIFALC_TDSTATE channel:0x0b frame:0 vi_tstamp:1810190182496 data:0x0000000031000003
     kworker/2:0-25      [002] ....  1786.273739: rtcpu_vinotify_event: tstamp:56568707657 cch:1 vi:0 tag:FS channel:0x00 frame:4 vi_tstamp:1810198566368 data:0x0000000400000010
     kworker/2:0-25      [002] ....  1786.273739: rtcpu_vinotify_event: tstamp:56568707790 cch:1 vi:0 tag:ATOMP_FS channel:0x00 frame:4 vi_tstamp:1810198566400 data:0x0000000000000800
     kworker/2:0-25      [002] ....  1786.273740: rtcpu_vinotify_event: tstamp:56568707939 cch:1 vi:0 tag:CHANSEL_EMBED_SOF channel:0x0b frame:4 vi_tstamp:1810198567456 data:0x0000000000000004
     kworker/2:0-25      [002] ....  1786.273740: rtcpu_vinotify_event: tstamp:56568708069 cch:1 vi:0 tag:CHANSEL_EMBED_EOF channel:0x0b frame:4 vi_tstamp:1810198581024 data:0x0000000000010008
     kworker/2:0-25      [002] ....  1786.273740: rtcpu_vinotify_event: tstamp:56568708221 cch:1 vi:0 tag:ATOMP_EMB_DATA_DONE channel:0x0b frame:4 vi_tstamp:1810198581600 data:0x0000000000000000
     kworker/2:0-25      [002] ....  1786.273740: rtcpu_vinotify_event: tstamp:56568708352 cch:1 vi:0 tag:VIFALC_ACTIONLST channel:0x0b frame:4 vi_tstamp:1810198588320 data:0x0000000003020002
     kworker/2:0-25      [002] ....  1786.273742: rtcpu_nvcsi_intr: tstamp:56568810512 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:0-25      [002] ....  1786.273742: rtcpu_nvcsi_intr: tstamp:56568810512 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004

hello paekaaa.paek,

first of all, may I confirm the Jetpack release version you’re working with?

the failure… class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
it meant packet payload CRC check has failed, but, you’ve also mentioned that 1st streaming with nvarguscamerasrc is always fine.

here’re couple of approaches for testing.
(1) please try restart Argus service before enabling the camera stream.
$ sudo pkill nvargus-daemon
$ sudo systemctl start nvargus-daemon
(2) please give it a try with below commands to boost all the VI/CSI/ISP clocks.
for instance,

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

Hello, JerryChang

I use Jetson r35.5.0.
And I tried your approaches but CRC error is not solved.
I used one or both of your approaches at the same time.

In addition, if I use another mode first after booting, CRC error occurs on second streaming.

booting → nvarguscamerasrc with another mode(good) → nvarguscamerasrc with 3840X2160 (almost crc error) → …

booting → nvarguscamerasrc with another mode(good) → nvarguscamerasrc with another mode(good) → …

thanks

hello paekaaa.paek,

did you meant CRC error only repo’ed by launching 3840X2160 sensor mode?

yes, CRC error only reported in 3840x2160 mode.

MIPI rate is different.
3840x2160 mode: chpy , 3 lanes, 887Msss
another modes: chpy , 3 lanes, 800Msps

hello paekaaa.paek,

please double check the Sensor Pixel Clock, which must be set correctly to avoid potential issues.

Hello, JerryChang

I already set px_clk_hz whcih is derived from MIPI rate.

px_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel
= 887Msps * 16/7 (cphy bits per symbol ) * 3 (lanes) / 10 (raw10)
= 608228572(round up) or 608228571(round down)
I tested both of values (608228572, 608228571) but it’s same result.

Is correct calculation?
Thanks

hello paekaaa.paek,

please give it another try with slightly higher pixel clock rate.
for instance, 610Mhz.

I tried many values of px_clk_hz (610,M 620M, 630M, 608228572~608228590) but same

There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks

Is this still an issue to support? Any result can be shared?