About the frame rate reduction problem of capture processing using CSI of Jetson TX2

Hello, ShaneCCC

Looking at the mmap buffer dump log, it looks like one frame is missing regularly. Isn’t it related to CRC error?

The situation after that
Supported CRC error correction with sensor (FPGA).
This resolved the CRC error on the TX2, but the frame rate remained at 30fps.

From these surveys
We focused on the wait condition in the nvhost_syncpt_wait_timeout_ext function.
Here, there was an unknown wait, and I thought it was the cause.

The nvhost_syncpt_wait_timeout_ext function seems to detect certain hardware interrupts.
A hardware interrupt counts up SyncPT.
When the threshold is exceeded, it seems to be released from the waiting process.

How many interrupts are there to count SyncPT?
Also, I want to know which interrupt signal is.

Do you have this information?

The nvhost_syncpt_wait_timeout_ext wait the FE if not receive FE during timeout time that will break the capture.

Hello, ShaneCCC

Thank you for your advice.
What we know is that FE events are not in 16msec cycles.
The cycle remains unchanged at 30 msec.
How can I check the status of FE events?

Sorry to tell, there’s no FE event status for checking.

Hello, ShaneCCC

Is there a solution to our problem?
Are there any solutions to similar problems in other columns?
Please provide information for a solution.

Hello, ShaneCCC

We refer to “Parker_SI_Errata_DA07897002v05 [7] .pdf” to solve the problem.
Is this choice correct?

The following correspondence that you taught me.
I misunderstood.
When I tried as you said, the FS / FE information was displayed.

However, none of the issues have been resolved.

Is there anything you can try?

Where didn’t you find Parker_SI_Errata_DA07897002v05 [7] .pdf
I have no idea to solve this problem now. Still consult with developer to find the root cause.

Hello, ShaneCCC

I tried to get the FS / FE log.

For some reason, frame 2 only logs FS and FE.
Do you know why?

kworker / 4: 0-17175 [004] .... 457.137454: rtcpu_vinotify_event: tstamp: 14581026205 tag: FS channel: 0x00 frame: 1 vi_tstamp: 14581025583 data: 0x00000010
kworker / 4: 0-17175 [004] .... 457.137455: rtcpu_vinotify_event: tstamp: 14581040022 tag: CHANSEL_PXL_SOF channel: 0x00 frame: 1 vi_tstamp: 14581039520 data: 0x00000001
kworker / 4: 0-17175 [004] .... 457.137456: rtcpu_vinotify_event: tstamp: 14580140179 tag: ATOMP_FS channel: 0x00 frame: 1 vi_tstamp: 14581039528 data: 0x00000000
kworker / 4: 0-17175 [004] .... 457.137456: rtcpu_vinotify_event: tstamp: 14581042198 tag: CHANSEL_LOAD_FRAMED channel: 0x01 frame: 1 vi_tstamp: 14581041835 data: 0x08000000
kworker / 4: 0-17175 [004] .... 457.137457: rtcpu_vinotify_event: tstamp: 14581546491 tag: CHANSEL_PXL_EOF channel: 0x00 frame: 1 vi_tstamp: 14581546083 data: 0x04af0002
kworker / 4: 0-17175 [004] .... 457.137457: rtcpu_vinotify_event: tstamp: 14581547634 tag: FE channel: 0x00 frame: 1 vi_tstamp: 14581546924 data: 0x00000020
kworker / 4: 0-17175 [004] .... 457.137457: rtcpu_vinotify_event: tstamp: 14581547765 tag: ATOMP_FE channel: 0x00 frame: 1 vi_tstamp: 14581546927 data: 0x00000000
kworker / 4: 0-17175 [004] .... 457.137458: rtcpu_vinotify_event: tstamp: 14585147901 tag: FS channel: 0x00 frame: 2 vi_tstamp: 14581546944 data: 0x00000010
kworker / 4: 0-17175 [004] .... 457.137458: rtcpu_vinotify_event: tstamp: 14582068798 tag: FE channel: 0x00 frame: 2 vi_tstamp: 14582068285 data: 0x00000020
kworker / 4: 0-17175 [004] .... 457.137459: rtcpu_vinotify_event: tstamp: 14582068933 tag: FS channel: 0x00 frame: 1 vi_tstamp: 14582068305 data: 0x00000010
kworker / 4: 0-17175 [004] .... 457.137459: rtcpu_vinotify_event: tstamp: 14582082734 tag: CHANSEL_PXL_SOF channel: 0x00 frame: 1 vi_tstamp: 14582082243 data: 0x00000001

It could be the time of the FE to FS too small cause it. Could be the same with below topic.

I would like to confirm that the cause may be that the time from FE to FS is too short.
Is the following log time stamp in nsec units?
tstamp: 14581547634

From the analysis result of the FS / FE event log
FS / FE has been generated, but CHANSEL_PXL_SOF has not been generated. In the system
Isn’t there a possibility that something is wrong with the CSIMUX block and CHANSEL block areas?

Do you have any advice?

That tell the channel was disable during that time. Sorry I don’t have much idea now.

Thank you for your reply
Is single shot mode affected?
Also, I asked a question before. I want to know the following answer.

Is the next log timestamp in nsec units?
tstamp: 14581547634

It’s ns

Hello, ShaneCCC

I have something to tell you.
Fixed the Vi driver to disable single shot mode.
This made it work at a frame rate of 60fps.
Is this correspondence correct?
I need your point of view.

We will continue to verify this as a permanent measure. I really want your opinion.

What’s do you mean single shot mode?

The following page describes SINGLE SHOT.
Parker_TRM_DP07821001p.pdf

27.24.4 VI_CH _CONTROL_0

How do you modify it. Suppose default is configure as SINGLE_SHOT?

        for (i = 0; i < chan->valid_ports; i++) {
                vi4_channel_write(chan, chan->vnc_id[i],
                        CHANNEL_COMMAND, LOAD);
                vi4_channel_write(chan, chan->vnc_id[i],
                        CONTROL, SINGLESHOT | MATCH_STATE_EN);
        }