Tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 4, flags: 0, err_data 131072

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

[Tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 4, flags: 0, err_data 131072](https://Problem description link)
Until now, we have not found the root cause. But after merging the codes of the depth camera and RGB camera, and conducting extensive testing, the above problem no longer exists. However, the codes of the depth camera and RGB camera are independent, and we don’t understand why this phenomenon occurs. Only loading the same RGB camera code will cause the above problem to occur.
I want to know whether nvcsi/vi clock will be set independently if several cameras are mounted on the SOC, or will it be configured according to one of the cameras with the highest performance requirements? Additionally, will low-power settings affect this aspect?

3

Does boost the clocks help on it?
What’s the trace log?

4

Boosting the clocks can only reduce the probability of occurring, but still happen. Trace log can be found in the link above.

5

I would suspect it could be the file write stock the buffer cause the problem.
Could you reduce the frame rate and output size to verify.

Thanks

6

I have reduced the frame rate from 30fps to 10fps，and the phenomenon persisted. The resolution of rgb camera is 640*480. Therefore, the amount of data is not large. The MIPI CSI Transmitter speed is configured to 800Mbps. When the rate is increased to 1.6Gbps, frame dropping occurs consistently. But I can confirm that this phenomenon is unrelated to the hardware signal quality.

7

Please check the trace log for more clue.

https://elinux.org/Jetson/l4t/Camera_BringUp

8

From the rtcpu_vinotify_error information in the trace log, combined with the VI error decoder map, I know the cause of the error, but I cannot find what led to the above error.

9

What’s the error?

10 
     kworker/4:2-109     [004] ....  1007.820214: rtcpu_vinotify_error: tstamp:32121868157 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x01 frame:2 vi_tstamp:1027899382080 data:0x00000003000000a0
     kworker/4:2-109     [004] ....  1007.820216: rtcpu_vinotify_event: tstamp:32122393130 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x01 frame:2 vi_tstamp:1027899382080 data:0x00000003000000a0
     kworker/4:2-109     [004] ....  1007.820217: rtcpu_vinotify_event: tstamp:32122393289 cch:0 vi:0 tag:CHANSEL_SHORT_FRAME channel:0x41 frame:2 vi_tstamp:1027899382112 data:0x01db200001000000

     kworker/4:2-109     [004] ....  1007.876201: rtcpu_vinotify_event: tstamp:32124454124 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:1027966097696 data:0x000000000802005d
     kworker/4:2-109     [004] ....  1007.876202: rtcpu_vinotify_error: tstamp:32124985404 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x41 frame:2 vi_tstamp:1027999405344 data:0x00000000000003c9
11

The short frame tell the output size less than expected. You modify the sensor driver to report less size to narrow it.

The CHANSEL_NOMATCH could be incorrect embedded_data_height in device tree.

12

I tried it, but it didn’t work.
I found that dynamic frequency scaling of the CPU affects frame drops from the camera. I want to consult about the impact of emc working frequency variations on the system and methods to fix the emc working frequency.
Additionally, when invoking the camera, the vi-output process appears, and I’m not sure why.

13

I don’t think the CPU frequency scaling would cause the problem.
You can run the nvpmodel -m and jetson_clocks to have CPU run in fix frequency to verify it.

14

“You can run the nvpmodel -m and jetson_clocks to have CPU run in fix frequency to verify it.”
—>I tested it, and it doesn’t work.
I checked the code with the camera manufacturer and didn’t find any suspicious points. Could you help take a look?

15

Maybe check the output size due to CHANSEL_SHORT_FRAME

17

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