Two cameras connected with one max9296 on R32.6.1

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hi,

I’m developing the camera driver for imx_490 with gw5300, max9295 and max9296 on ROScube.

The driver works well except the case of two camera connected with one max9296 on R32.6.1.

But it works fine on R32.5.1. The followings are condition and environment for the issue on R32.6.1, and which is the same as those for R32.5.1.

  1. The camera drivers are the same as those of R32.5.1 at binary level.

  2. DTBs for both release are generated by applying the same overlay dtb.

  3. Cameras are connected with Port 1 & 2.

  4. Video image format is YUV422.

  5. Video image size is W:2880 H:1860.

  6. Start streaming on each camera by gstreamer with 10 fps mode.

I found out the followings

  1. The status registers for pipes on max9295 and max9296 showed “working without error” in the both release.

  2. The first camera to start streaming was able to display video image

  3. The second camera to start streaming was unable to display video image.

Any help would be appreciated.

dmesg.log.gz (24.5 KB)
tracelog.txt.gz (121.5 KB)

1 Like
3

Boost the clocks to try.

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
4

Hi @k.iwasaki
Can you open either link A or link B camera on R32.6.1 or just link A camera ?

You could use the following tips to debug this:

  1. gstreamer render green screen: no video received. It might be caused by MIPI lanes and MAX9296 pipeline incorrectly configuration.
  2. check MAX9296 (0x48) video lock register (0x1DC => Pipeline X, 0x1FC => Pipeline Y, 0x21C => Pipeline Z, 0x23C => Pipeline U). If value is 0x01 which means there’s valid video on this pipeline), if value is 0x00, you might need to check your pipeline setting.
  3. Make sure your serializer’s video is send by which stream id (st_id_sel in your code), this ID should match MAX9296 side pipeline’s receiving ID. e.g. MAX9296 0x50 = 0x02 , pipeline X is receiving stream ID = 2 from serializer.
5

Thanks, ShaneCC-san
I tried the boost, but it made no difference to the results.

Thanks, chester.tseng-san.

gstreamer renders not green screen but background color of the desktop without the message " no reply from camera sensor…" on serial console. From my experience, the message “no reply from camera sensor…” is displayed on the serial console whenever gstreamer renders green screen.

checked the registers value and stream id and the value of the str_len acording to you advise.
I think there is no problem.

My code for the max9295 and max926 are resumble

  1. variable st_id_sel for link A is 0x02 and for link B is 0x03.

  2. All of the lock registers are 0x01.

  3. max9296 pipeline regsiters value
    address value
    [0x0050] = 0x02
    [0x0051] = 0x03
    [0x0052] = 0x02
    [0x0053] = 0x03
    [0x0053] = 0x03

As I mentioned before, even though two cameras connected with one max9296, I can see the video image from both of them on R32.5.1. with my drivers. It is no problem on R32.5.1 at all.

Even though two cameras connected with one max9296, gstreamer shows the video image from both of them on R32.5.1 with my drivers. I already confirmed the configuration for max9295 and max9296 was same as that for R32.6.1 by checking the values for all of the registers and variables to be written on max9295 and max9296. I have tried decreasing the CSI clock hz (by setting register at 0x320 ) from max9296 because the message like below appeared sometime.

kworker/7:3-2240  [007] ....   311.716528: rtcpu_nvcsi_intr: tstamp:10670073106 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
kworker/7:3-2240  [007] ....   311.716528: rtcpu_nvcsi_intr: tstamp:10670074219 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004

I thought it was too high ( 1800Mhz : written value is 0x32). So I set the value to 0x2F(1500Mhz) , then I was able to see the video image from both cameras at 1 time in 2 times. But the stremaing the video image was stopped at the first frame when I set the value to 0x2C(1200Mhz).

6

The error tell the CRC error in the payload data. err_intr_stat_pd_crc_err_vc0

7

The error has gone and I have not seen it even if csi clock is set to 1800Mhz in the trace log since two days ago.

Further, I have found out the error below. I don’t understand why I get this error in the trace log which I uploaded when I created this topic.

 kworker/0:2-1185  [000] ....   230.566817: rtos_queue_peek_from_isr_failed: tstamp:8133576327 queue:0x0bcbbbb8
 kworker/0:2-1185  [000] ....   230.566819: rtcpu_vinotify_error: tstamp:8133917999 tag:CHANSEL_NOMATCH channel:0x04 frame:0 vi_tstamp:8133917062 data:0x000003c9
 kworker/0:2-1185  [000] ....   230.566820: rtcpu_vinotify_event: tstamp:8133918272 tag:FS channel:0x00 frame:0 vi_tstamp:8133866334 data:0x00000012
 kworker/0:2-1185  [000] ....   230.566838: rtcpu_vinotify_event: tstamp:8133918397 tag:CHANSEL_NOMATCH channel:0x04 frame:0 vi_tstamp:8133917062 data:0x000003c9
 kworker/0:2-1185  [000] ....   230.566839: rtcpu_vinotify_error: tstamp:8134126887 tag:CHANSEL_NOMATCH channel:0x44 frame:0 vi_tstamp:8134125967 data:0x000003c9
 kworker/0:2-1185  [000] ....   230.566840: rtcpu_vinotify_event: tstamp:8134234190 tag:FS channel:0x01 frame:0 vi_tstamp:8134075017 data:0x00000012
 kworker/0:2-1185  [000] ....   230.566841: rtcpu_vinotify_event: tstamp:8134234315 tag:CHANSEL_NOMATCH channel:0x44 frame:0 vi_tstamp:8134125967 data:0x000003c9

I guess it means that VI sets up the channel 0x04 and 0x44 for YUV422 data, and that the actual data format is not YUV422. I’d like to check the actual data in VI. How can I get the data from VI ?

8

Suggest consulting with Max to confirm if any embedded data output to modify the embedded_metadata_height in device tree.

9

It is able to see the video stream image of each port one by one with embedded_data_height=0 in DTB. So I don’t think the embedded data is attached to the video image data.
I don’t think VI or CSI driver works well in this case. Because there is no difference except L4T codes and because I confirmed there were many differences between the VI and CSI codes in R32.5.1 and those in R32.6.1 with executing diff.

11

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