MIPI camera performs stably on Orin Nano Devkit (P3767-0005), but is unstable on the Commercial module (P3767-0003)

MIPI camera performs stably on Orin Nano Devkit (P3767-0005), but is unstable on the Commercial module (P3767-0003).

Test Conditions:

  1. Both use the P3768 carrier board.
  2. Use the same Nvme SSD, which contains the JP5.1.3 version system.

Test Method:

  1. The camera resolution is 5M@20fps, using v4l2-ctl to capture images.
  • Camera0
v4l2-ctl -d /dev/video0 --set-fmt-video=width=2592,height=1944,pixelformat=UYVY --stream-mmap --stream-count=-1 --stream-to=/dev/null
  • Camera1
v4l2-ctl -d /dev/video1 --set-fmt-video=width=2592,height=1944,pixelformat=UYVY --stream-mmap --stream-count=-1 --stream-to=/dev/null

Problem Description:

  1. Using P3767-0005 and P3767-0003, if only one camera’s image is read at a time, it is stable.
  2. When reading images from both cameras simultaneously, it is stable using the P3767-0005 board; however, using the P3767-0003 board, errors occur quickly, as shown below:
[131728.695584] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[131728.709656] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[131728.720001] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[131728.730422] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[131728.740811] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[131728.751147] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[131756.800248] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[131756.809519] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[131756.819229] (NULL device *): vi_capture_control_message: NULL VI channel received
[131756.827065] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=1, csi_port=1
[131756.837855] (NULL device *): vi_capture_control_message: NULL VI channel received
[131756.847053] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[131759.360481] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[131759.369751] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[131759.379459] (NULL device *): vi_capture_control_message: NULL VI channel received
[131759.387279] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=1, csi_port=1
[131759.398054] (NULL device *): vi_capture_control_message: NULL VI channel received
[131760.416298] tegra194-vi5 13e40000.host1x:vi0@15c00000: capture control message timed out
[131760.424763] tegra194-vi5 13e40000.host1x:vi0@15c00000: vi_capture_control_send_message: failed to send IVC control message

My Attempts:

  1. I followed the camera bringup steps to trace the error logs. However, due to the excessive information from cat /sys/kernel/debug/tracing/trace, the frame rate significantly drops, making it difficult to effectively debug.
  2. I tried increasing serdes_pix_clk_hz, but it was ineffective.
  3. I attempted to boost the clock for debugging, but it was ineffective.
  4. I looked for hardware differences between P3767-0005 and P3767-0003. So far, I believe the only difference is that P3767-0005 has an SD card slot, but everything else is the same.

Request:

Do you have any debugging suggestions for me?

  1. Clean the log by “echo > /sys/kernel/debug/tracing/trace”
  2. Run the cameras
  3. Get the trace log “cat /sys/kernel/debug/tracing/trace > t.log”

@ShaneCCC
Thank you for your suggestion.

However, unlike the similar problems I’ve encountered before, this time once an error occurs, the Linux operating system crashes rapidly, and the network, mouse, and keyboard become unresponsive, making it impossible for me to collect logs according to your method.

The serial port log is attached in the appendix.
serial_err_log.txt (5.9 KB)

OK, please increase below to 2500*4

#define CAPTURE_TIMEOUT_MS 2500

@ShaneCCC
Here’s part of the log I caught.

     kworker/4:1-47      [004] ....    76.158102: rtcpu_vinotify_event: tstamp:3387493943 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:108399538944 data:0x0000000002020004
     kworker/4:1-47      [004] ....    76.158104: rtcpu_vinotify_error: tstamp:3387517028 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x02 frame:1 vi_tstamp:108400404736 data:0x00000000000003c9
     kworker/4:1-47      [004] ....    76.214292: rtcpu_vinotify_event: tstamp:3387994467 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:108399563840 data:0x0000000000020004
     kworker/4:1-47      [004] ....    76.214294: rtcpu_vinotify_event: tstamp:3387994728 cch:0 vi:0 tag:FS channel:0x00 frame:1 vi_tstamp:108400402688 data:0x0000000100000011
     kworker/4:1-47      [004] ....    76.214295: rtcpu_vinotify_event: tstamp:3387995010 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x02 frame:1 vi_tstamp:108400404736 data:0x00000000000003c9
     kworker/4:1-47      [004] ....    76.214297: rtcpu_vinotify_error: tstamp:3389079655 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x02 frame:1 vi_tstamp:108450404064 data:0x00000000000003c9
     kworker/4:1-47      [004] ....    76.214298: rtcpu_vinotify_event: tstamp:3389084192 cch:0 vi:0 tag:FE channel:0x00 frame:1 vi_tstamp:108449485504 data:0x0000000100000021
     kworker/4:1-47      [004] ....    76.214298: rtcpu_vinotify_event: tstamp:3389084471 cch:0 vi:0 tag:FS channel:0x00 frame:1 vi_tstamp:108450402016 data:0x0000000100000011
     kworker/4:1-47      [004] ....    76.214299: rtcpu_vinotify_event: tstamp:3389084712 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x02 frame:1 vi_tstamp:108450404064 data:0x00000000000003c9
     kworker/4:1-47      [004] ....    76.270106: rtcpu_vinotify_error: tstamp:3390641989 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x02 frame:1 vi_tstamp:108500403424 data:0x00000000000003c9

rtcpu_vinotify_error: tstamp:3387517028 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x02 frame:1 vi_tstamp:108400404736 data:0x00000000000003c9

DTYPE:NvCsiDataType_YUV422_8 ---- correct,
CTYPE:LS line start.

What exactly does this log mean in terms of problems, please?

@ShaneCCC
I reran the test and grabbed all the logs, but there is nothing out of the ordinary. Please refer to the attachment for the logs.
t.log (1.4 MB)

Didn’t see any suspect error from this log. Does this get by launch 2 cameras?

Yes.
I tried changing the output of the camera to clock continuous mode and it seems to be working fine so far.
I have found that the mipi signal is very demanding on the Orin platform, especially clock discontinous mode.

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