Camera lose the frame sometimes

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

we use the TX2-NX board on Version 32.7.2
we use the camera ISX019，10fps， Due to hardware reasons, when we use the trigger signal, there will be a loss of 5 frames

while we use the normal v4l-ctl common like this

v4l2-ctl --set-ctrl --set-ctrl bypass_mode=0 --stream-mmap  -d /dev/video0

it can see like that

<<<<<<<<<< 10fps
<<<<<<<< 9fps
<<<<<<< 8fps
<<<<<<<<<< 9fps

This is reasonable and what we expected

But sometimes, after the synchronization signal is generated, the following situation occurs, and the frame rate seems to have decreased by half

it can see like that

<<<<<<<<<< 10fps
<<<<<<<<<< 10fps
<<<<< 8fps
<<<< 8fps
......
<<<<< 5fps
<<<< 5fps

This will be lose many frames

and dmesg show that always

tgra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
tgra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
tgra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
tgra-vi4 15700000.vi: ATMOP_FE syncpy timeout! err = -11
tgra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
......

But we can observe the mipi signal as 10fps using an oscilloscope

And if you open the image, it can be displayed, but you can see the lag

3

hello miaofeiyu1991,

may I know the actual hardware configuration, did you meant it’s an external trigger?

4

Hi Jerry
Yes , it is a external trigger,
This is a synchronization signal. If there is an inaccurate signal, the camera signal will lose 3-5 frames and then go back to normal. The loss of 3-5 frames is acceptable, but occasionally there may be situations where the image cannot be obtained at the normal frame rate (10fps). We cannot understand this. I tried to modify the timeout of channal in vi4 fops, but this problem still seems to exist, Just didn’t report an error

5

hello miaofeiyu1991,

camera device is now passive, and waiting for triggers for sending frames.
timeout from low-level driver side has reported, it means VI cannot receive a frame.

there’ll be no frames as long as not sending trigger, so, this should be an issue on external trigger side.

6

This is not a problem with external signals. We can capture the normal mipi signal, which is determined to be a 10fps signal, but v4l2 can only capture about half of frame

7

according to this.
it’s VI waiting for start-of-frame signal has timed out.

8

But I don’t perform any register operations, and just restart the video(This process does not operate on any registers), and the image can be displayed normally

9

hello miaofeiyu1991,

let me have clarification.
VI driver it uses sync-point. (i.e. syncpt) to communicate with sensor streaming.
it’s below code snippet to wait for PXL_SOF syncpt, it should receive start-of-frame for every 100ms since it’s a 10-fps sensor.

                err = nvhost_syncpt_wait_timeout_ext(chan->vi->ndev,
                                chan->syncpt[i][SOF_SYNCPT_IDX], thresh[i],
                                chan->timeout, NULL, NULL);

you’re running with single thread approach, right?
please also check this is actually be called to request for every frame.
for example,

static int tegra_channel_capture_frame_single_thread 
...
                /* wait for vi notifier events */
                if (!vi_notify_wait(chan, buf, &ts)) {

if yes…
please give it a try with running below commands to boost all the VI/CSI/ISP clocks.

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
10

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