Frame dropped in MIPI DPHY 2.5 Gbps, but 2.4 Gbps works

[ting.chang]

Hi there,

We are using our customized PCB for AGX Orin. The PCB contains four MAX96712.

When we connect each MAX96712 with two 8M cameras and configured DPHY with 2.5 Gbps, frame drop happens frequently for the image frames come from CSI-6 and CSI-7. The other image frames from the other CSI ports received without frame drop.

However, if we reduce the DPHY rate to 2.4 Gbps, all the images frames received without frame drop.

In 2.5 Gbps configuration, the error trace log are listed below:

kworker/2:2-5410    [002] ....  4688.775679: rtcpu_vinotify_error: tstamp:149704413335 cch:0 vi:1 tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:4790541155200 data:0x0000000000400065
kworker/2:2-5410    [002] ....  4688.775682: rtcpu_vinotify_error: tstamp:149704455191 cch:0 vi:1 tag:CHANSEL_NOMATCH channel:0x20 frame:0 vi_tstamp:4790542485152 data:0x00000000000003c9
kworker/2:2-5410    [002] ....  4688.775685: rtcpu_vinotify_event: tstamp:149704505554 cch:0 vi:1 tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:4790541155200 data:0x0000000000400065
kworker/2:2-5410    [002] ....  4688.775686: rtcpu_vinotify_event: tstamp:149704505686 cch:0 vi:1 tag:FS channel:0x00 frame:0 vi_tstamp:4790541243232 data:0x0000000000000015
kworker/2:2-5410    [002] ....  4688.775686: rtcpu_vinotify_event: tstamp:149704505838 cch:0 vi:1 tag:CHANSEL_NOMATCH channel:0x20 frame:0 vi_tstamp:4790542485152 data:0x00000000000003c9
kworker/2:2-5410    [002] ....  4688.775687: rtcpu_vinotify_error: tstamp:149704567806 cch:1 vi:1 tag:CSIMUX_FRAME channel:0x02 frame:0 vi_tstamp:4790546098464 data:0x0000000000400065
kworker/2:2-5410    [002] ....  4688.775687: rtcpu_vinotify_error: tstamp:149704609718 cch:1 vi:1 tag:CHANSEL_NOMATCH channel:0xa0 frame:0 vi_tstamp:4790547430112 data:0x00000000000003c9
kworker/2:2-5410    [002] ....  4688.775688: rtcpu_vinotify_event: tstamp:149704830808 cch:1 vi:1 tag:CSIMUX_FRAME channel:0x02 frame:0 vi_tstamp:4790546098464 data:0x0000000000400065
kworker/2:2-5410    [002] ....  4688.775688: rtcpu_vinotify_event: tstamp:149704830960 cch:1 vi:1 tag:FS channel:0x02 frame:0 vi_tstamp:4790546188224 data:0x0000000000000015
kworker/2:2-5410    [002] ....  4688.775689: rtcpu_vinotify_event: tstamp:149704831091 cch:1 vi:1 tag:CHANSEL_NOMATCH channel:0xa0 frame:0 vi_tstamp:4790547430112 data:0x00000000000003c9

I wonder what is the reason to cause “frame drop” when using 2.5 Gbps, thank you.

[JerryChang]

hello ting.chang,

is it due to system loading? please check you’ve already running in MaxN performance mode.
please also enable tegrastats utility to gather usage reports.
for instance, $ sudo tegrastats --interval 5000 --logfile <out_file> &

[ting.chang]

Hi Jerry,

Thank you for your reply. The frame drop still happens even if there is only one 8M camera running in MaxN mode. Also, it happens only with the MAX96712 connected to CSI-6 and CSI-7

I’ve monitored the CPU load by Jetson Power GUI. The CPU load for all the CPU cores are low before frame drop happening. After a while, the frame drop happens, and one CPU core immediately reaches 100% at the same time.

Please check the the tegrastats report.
8m_frame_drop.txt (4.3 KB)

[JerryChang]

@ting.chang

Also, it happens only with the MAX96712 connected to CSI-6 and CSI-7

hello ting.chang,

it may due to trace length, had you try configure higher pixel clock to test this specifically?

[ting.chang]

@JerryChang

it may due to trace length, had you try configure higher pixel clock to test this specifically?

Hi Jerry,

Thank you.
I’ve modified the serdes_pix_clk_hz from “600000000” to “625000000”.
The problem seems disappear.
I will update the result after a long time test.

[ting.chang]

Sorry, it still fails with higher serdes_pix_clk_hz…

[ting.chang]

Is it related to MIPI DPHY deskew?
I’m not sure when should I write the MAX96712 registers to enable the initial deskew and periodic deskew.

[JerryChang]

you may see-also Topic 268833 to apply camera firmware update for verification.

[ting.chang]

Hi @JerryChang

Do you know if deskew is not configured on SerDes, what kind of effect will happen on Orin?

• Receive no image frames when start streaming?
• Frame dropped while streaming?
• Both of the above two?

[JerryChang]

hello ting.chang,

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps
the camera firmware will continue to wait for deskew signal from the sensor side, it’ll enable pixel parser when deskew calibration has completed.

[ting.chang]

Just sharing my experience.

I’ve confirmed that if deskew signal is not given, the v4l2-ctrl will not receive any frames, and the dmesg error just like camera not streaming:

tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
(NULL device *): vi_capture_control_message: NULL VI channel received

In that situation, if I access the Deserializer register to send deskew signal, the v4l2-ctrl immediately receives images.

However, in my case, whether the frame drop during video streaming is related to deskew or not? I have no idea yet. Since the MIPI trace length of the CSI-6/7 is the shortest than the other CSI ports.