720p camera source with incorrect or missing st352 payload not working

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi,
My use-case is an avionics DVR.
I am using Linux R35.5.0 (Jetpack 5.1.3) with custom carrier board.
I have modified the device tree and ov5693 driver to support camera capture from an FPGA.

I am having issues with some 720p60 sources where VI engine never receives frames. It seems that this happens if the source does not have an ST352 payload packet or if the ST352 data is wrong.
Question#1: Does Jetson require an ST352 payload for a 720p HD video source ?

If I power up jetson with a source that has ST352 payload and then start capture, capture works. If I stop capture and reconnect to a source without an ST352 payload then capture still works. This indicates to me that mipi hardware/firmware needs to detect ST352 at least once.

If I power up jetson with a source that does not have an ST352 payload and then start capture, capture fails. If I stop capture and reconnect to a source with ST352 payload then capture still does not works. This indicates to me that jetson mipi hardware/firmware is now locked up from first capture without ST352. Only way to get jetson capture working again with source with ST352 is to power cycle jetson. If I just reboot the kernel capture is still broken.
Question #2 Why do I need to power cycle to get capture working again?
Seems that kernel reboot does not reset capture hardware/firmware.
Question #3 Is this correct?

Question#4: Can you please share version of camera-rtcpu-t194-rce.img which collects more info in trace log with me.

Thanks!

Trace log of capture with source that has no ST352 payload:

TASK-PID CPU# |||| TIMESTAMP FUNCTION

| | | |||| | |

 kworker/4:2-104     [004] ....    45.764573: rtcpu_string: tstamp:2027108325 id:0x04010000 str:"VM0 deactivating."
 kworker/4:2-104     [004] ....    51.308606: rtcpu_string: tstamp:2201399091 id:0x04010000 str:"VM0 activating."
 kworker/4:2-104     [004] ....    51.364597: rtcpu_vinotify_event: tstamp:2202045817 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:70448666368 data:0xcd9ce50010000000
 kworker/4:2-104     [004] ....    51.364599: rtcpu_vinotify_event: tstamp:2202045966 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:70448678112 data:0x0000000031000001
 kworker/4:2-104     [004] ....    51.364600: rtcpu_vinotify_event: tstamp:2202046130 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:70448733216 data:0xcd9ce20010000000
3

I don’t think so.
Suppose most user don’t have ST352, what’s ST352 for your case?

4

We are using SDI cameras and SDI generators as sources to test the SDI->FPGA->JETSON-MIPI path. Some cameras do not have ST352 data in payload. Those are the ones we are having issues with.

Can you please share the debug version of camera-rtcpu-t194-rce.img which collects more info in trace log.

How can I check if any MIPI data is being received by Jetson in case the issue is in the Xilinx SDI to MIPI IP? Is there a way to make the Jetson side (rtcpu/ vi-engine) more verbose apart from trace log?

5

Suppose enable the trace log would be enough.

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 3 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace
7

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