Mipi-driver : frame start syncpt timeout!0

Hello Jerry,
Thanks for your respone. I have changed TEGRA_CLOCK_CSI_PORT_MAX to 50MHZ but there is no change in error(SOT multi bit error in data_lane 1). Is any other solution for debug it. Thanks.

Hi Jerry,
After changing custom sensor data rate to 1.3GBps and in driver chan->timeout = msecs_to_jiffies(1000), I can able to read My first packet. Thanks for your support.
Now issue is I can able to read only 1fps and My sensor sending 4 packets per second but I can read only first packet. I have a doubt that why my sensor need chan->timeout = msecs_to_jiffies(1000) and imx219 just enough chan->timeout = msecs_to_jiffies(200).
Could you please give me any idea to debug it. Thanks a lot.
I have attached my dmesg.

hello AlbinRaj0,

glad to know you had some progress.

there’re frame_start and mw_ack_done for waiting hardware sync-points of frame-start and frame-end sensor signaling.
the hardware sync-points using different index to indicate this, for example, chan->syncpt[index][0] for frame_start; chan->syncpt[index][1] for mw_ack_done.

it’ll only looking for frame_start if you’re using single thread approach for frame captures,
for example,

static int tegra_channel_capture_frame(struct tegra_channel *chan,
                                        struct tegra_channel_buffer *buf)
        if (chan->low_latency)
                ret = tegra_channel_capture_frame_multi_thread(chan, buf);
                ret = tegra_channel_capture_frame_single_thread(chan, buf);

that MW_ACK_DONE sync-point timeout error should be caused by waiting timeout for the last frame to terminate the capture process.
you might have a try to increase the timeout limitation for verification.

Hi Jerry.
Thanks for information. I have tried multi thread approach also, but result is same, it’s reading only 1fps. Is any other solution for reading 4fps. And why its reading only one frame and Is I want to enable any register for interlaced support. Thanks.

hello AlbinRaj0,

all the reference camera driver we’re currently had were based-on continuous mode.
since the camera driver development is the same as continuous mode camera, but frame input is different.
is it possible to configure it as continuous mode for verification? may I know what’s the use-case of interlaced more.

Hello Jerry,
Thanks for your response. I will try to configure My sensor as continuous mode. For continuous mode only I mentioned as interlaced mode. My sensor sending 4 packet in one second but I found that driver is taking one second to processing first packet itself that why it’s missing all other packet and always reading first packet only.
Could you give any Idea why it’s taking one second(chan->timeout = 250) for reading packet. Thanks for your time.

hello AlbinRaj0,

may I know what’s contents of these 4 packets, thanks

Hi Jerry,
It contain just Hex character. Example packet one contain 0xFF (256 bytes), packet 2 contain 0x00( 256 ) packet 3 contain 0xCC( 256 bytes) and packet 4 contain 0xDD (256 bytes). When my sensor sending this packet to jetson nano I can read only 0xFF(256 bytes). Could you please suggest any idea to debug it.
Thank for your support.

hello AlbinRaj0,

since we don’t such sensor to output single row data for validation, I can only imagine there’s signal to indicate the end of package, which makes VI to recognize it as frame-end.

Hi Jerry,
I am happy to say that we found the issue that is present in Virtual channel ID. Thank lot for you support. I praise God for your support.

1 Like