Cannot capture from adv7280m with Jetpack-4.6.1

Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks

Hi @kayccc,

The issue is still there unfortunately. Sometime it can work after a certain retries of gst-launch but the number of retries until the successful capture is quite random. I might wait for next Jetpack release to test again as I don’t think there’s big change in the kernel BSP btw the working Jetpack-4.5.1 and the faulty BSP Jetpack-4.6.1 and my driver is exactly the same in the 2 versions.

Regards,
K.

Hi @ShaneCCC ,
nvpmodel -m 2 and jetson_clocks did not resolve my problem.

Rest regards,
K

Check it able output test pattern to verify.

Hi @ShaneCCC ,

Yes, it is able to output the test pattern (Color Bar), the only doubt is that I am not sure that it was a stream of test pattern or only some first images of the test pattern. However, it does show the test pattern right after launching the gstreamer command, while with images from real scene, first frames seem to be discarded and gstreamer shows nothing.

Best Regards,
Khang

If test pattern without problem that tell the adv7280 to NX without problem.

Hi @ShaneCCC ,

It seemed that only first frame(s) is/are captured. Running following command does not report any fps as it is blocking :

v4l2-ctl --device /dev/video1 --set-fmt-video=width=720,height=507,pixelformat=UYVY,field=interlaced --set-ctrl bypass_mode=0 --stream-mmap --stream-count=200

Best Regards,
K.

Test pattern?
Any different in the trace log?

Hi @ShaneCCC ,

Test pattern?
Yes.

Attached are the logs with test pattern enabled by following steps :
Root console :

root@JetsonXNX:/home/toto/Workspace# ./max_clock.sh 
vi clock rate is:460800000
isp clock rate is:576000000
emc clock rate is:1600000000
nvcsi clock rate is:314000000

User console :
./i2c_set_regs.sh 8 ADV7280M_ColorBar_480p.txt && gst-launch-1.0 v4l2src device=/dev/video1 ! xvimagesink

or
./i2c_set_regs.sh 8 ADV7280M_ColorBar_480i.txt && gst-launch-1.0 v4l2src device=/dev/video1 ! xvimagesink

Best Regards,
K

toto_progressive.txt (5.0 MB)
for following setting :
ADV7280M_ColorBar_480p.txt (1.0 KB)

And
toto_interlaced.txt (570.2 KB)
for following setting :
ADV7280M_ColorBar_480i.txt (679 Bytes)

The trace log tell the SPURIOUS data after the SOF. That could be the user define data cause the problem.
Have a check with vendor if able to disable the user define data package for trying.

kworker/1:2-1918 [001] … 457.471648: rtcpu_vinotify_error: tstamp:14760981581 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:14760980728 data:0x00010000

Hi @ShaneCCC ,
Thanks for your suggestion. I will check the registers settings ( ADV7280M_ColorBar_480p.txtor ADV7280M_ColorBar_480i.txt) first. But, I am confused that I was working with previous jetpack release (r32.5.1) with same configuration, still.

Regards,
Khang

On the same platform?

Maybe you can try modify the VI driver to ignore the err to try. Remove the goto uncorr_err;

static void vi5_capture_enqueue(struct tegra_channel *chan,
395  	struct tegra_channel_buffer *buf)
396  {
397  	int err = 0;
398  	unsigned int vi_port;
399  	unsigned long flags;
400  	struct tegra_mc_vi *vi = chan->vi;
401  	struct vi_capture_req request[2] = {{
402  		.buffer_index = 0,
403  	}, {
404  		.buffer_index = 0,
405  	}};
406  
407  	for (vi_port = 0; vi_port < chan->valid_ports; vi_port++) {
408  		vi5_setup_surface(chan, buf, chan->capture_descr_index, vi_port);
409  		request[vi_port].buffer_index = chan->capture_descr_index;
410  
411  		err = vi_capture_request(chan->tegra_vi_channel[vi_port], &request[vi_port]);
412  
413  		if (err) {
414  			dev_err(vi->dev, "uncorr_err: request dispatch err %d\n", err);
415  			goto uncorr_err;
416  		}
417  
418  		spin_lock_irqsave(&chan->capture_state_lock, flags);
419  		if (chan->capture_state != CAPTURE_ERROR) {
420  			chan->capture_state = CAPTURE_GOOD;
421  			chan->capture_reqs_enqueued += 1;
422  		}
423  		spin_unlock_irqrestore(&chan->capture_state_lock, flags);
424  		buf->capture_descr_index[vi_port] = chan->capture_descr_index;
425  	}
426  	chan->capture_descr_index = ((chan->capture_descr_index + 1)
427  					% (chan->capture_queue_depth));
428  
429  	spin_lock(&chan->dequeue_lock);
430  	list_add_tail(&buf->queue, &chan->dequeue);
431  	spin_unlock(&chan->dequeue_lock);
432  
433  	wake_up_interruptible(&chan->dequeue_wait);
434  
435  	return;
436  
437  uncorr_err:
438  	spin_lock_irqsave(&chan->capture_state_lock, flags);
439  	chan->capture_state = CAPTURE_ERROR;
440  	spin_unlock_irqrestore(&chan->capture_state_lock, flags);
441  }
442  

On the same platform?
Yes, on the same custom board based on Jetson Xavier NX module (same module as well).

As per your suggestion, I modified the vi5_fops.c as below :

diff --git a/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c b/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
index 71a9b48de..56a1f8a2e 100644
--- a/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
+++ b/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
@@ -359,7 +359,7 @@ static void vi5_capture_enqueue(struct tegra_channel *chan,
 
                if (err) {
                        dev_err(vi->dev, "uncorr_err: request dispatch err %d\n", err);
-                       goto uncorr_err;
+//                     goto uncorr_err;
                }
 
                spin_lock_irqsave(&chan->capture_state_lock, flags);
@@ -381,7 +381,7 @@ static void vi5_capture_enqueue(struct tegra_channel *chan,
 
        return;
 
-uncorr_err:
+//uncorr_err:
        spin_lock_irqsave(&chan->capture_state_lock, flags);
        chan->capture_state = CAPTURE_ERROR;
        spin_unlock_irqrestore(&chan->capture_state_lock, flags);

However, I was not able to stream still. And the error has always been :

[  106.219027] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[  106.234901] tegra194-vi5 15c10000.vi: corr_err: discarding frame 2, flags: 0, err_data 131072
[  106.239106] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[  106.255611] tegra194-vi5 15c10000.vi: corr_err: discarding frame 2, flags: 0, err_data 131072

not the one related to the modified code :

dev_err(vi->dev, "uncorr_err: request dispatch err %d\n", err);

Regards,
K

Hi @ShaneCCC,

Another observation is that with following command for measuring fps, it seems that there’s some first frames are captures (as I said before) and the numbers of captured frames (represented by < ) are random :

l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<<<<<<<<<<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<<<<<<<<<<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100  -d /dev/video1
<<<<^C

^C = I forced to exit the command when it did not progress anymore.

Hi @ShaneCCC ,

By the way, do you think that following issue is relevant : IMX219 Raw8 mode on the XavierNX: Disabling CRC - #9 by ShaneCCC ?

I am not sure if it disable the SPURIOUS too, Could you please help to try it.

Thanks

Hi @ShaneCCC ,
I applied the same patch for drivers/media/platform/tegra/camera/nvcsi/csi5_fops.c as you proposed here : IMX219 Raw8 mode on the XavierNX: Disabling CRC - #9 by ShaneCCC. The issue still persists.

But I wondered if I would need to update the camera-rtcpu-rce.img as it seems to be the same version btw Jetpack-4.5 and Jetpack-4.6.

Regards,
Khang

Yes, the rtcpu firmware must need update.

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