IMX477 dual camera fails through CSI-to-HDMI extender (NvBufSurfaceFromFd Failed) — works fine with short cable. How to lower CSI signal rate?

Hello,

I’m running a dual IMX477 setup on a Jetson Orin Nano (Super) with the official p3768 carrier, JetPack R36.5.0 (kernel 5.15.185-tegra). The two cameras are configured through the native dual overlay tegra234-p3767-camera-p3768-imx477-dual.dtbo, and the application uses DeepStream. This is for a permanent art installation, where the cameras need to sit about 1.3 meters away from the Jetson, so I’m using a pair of Arducam UC-392 passive CSI-to-HDMI adapters with a high-speed HDMI cable in between.

The setup worked reliably for several weeks, then started failing. I’ve now isolated the problem cleanly, testing a single camera (sensor-id=0) and changing only the cable.

With a short direct CSI cable (~30cm), in mode 1 (1080p@60), capture succeeds — I get a clean Got EOS after 120 buffers. With the same camera through the UC-392 + ~1.3m HDMI cable, mode 1 fails immediately with NvBufSurfaceFromFd Failed (threadExecute:760). If I try mode 0 (4K@30) through the extender, I instead get INVALID_SETTINGS / Argus Correctable Error Status.

In all cases V4L2 detects both cameras correctly; the failure appears only in Argus, and only when the extender is in the path. This strongly points to CSI signal integrity at the high pixel clock over the longer HDMI run, rather than a software or driver problem.

The current sensor mode configuration from the active overlay is:

num_lanes = “2”

tegra_sinterface = “serial_b” / “serial_c”

discontinuous_clk = “no”

pix_clk_hz = “300000000”

mclk_khz = “24000”

My question is essentially how to make the CSI link more tolerant over this extended path. Specifically:

Would setting discontinuous_clk = “yes” for the IMX477 be safe and help with marginal signal integrity over the longer cable? Is reducing pix_clk_hz a valid way to lower the CSI rate, and if so, which values are valid for the IMX477 1080p mode — or does the sensor only support discrete clock configurations? And are there other parameters you’d recommend tuning (for example cil_settletime or deskew/settle settings) to improve tolerance for a longer CSI-over-HDMI extension?

Any guidance on the right approach here would be greatly appreciated. I can provide full Argus logs, dmesg output, or RTCPU trace logs if useful.

Thank you very much

— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —

To address the issue of the Jetson Orin Nano IMX477 dual camera failing through a CSI-to-HDMI extender, with the error “NvBufSurfaceFromFd Failed” when using a longer cable, while working fine with a short cable, we need to consider the signal integrity and potential adjustments to the CSI link configuration.

  1. Setting discontinuous_clk = yes: This setting is related to the clocking scheme used by the camera sensor. Setting discontinuous_clk = yes can potentially help with signal integrity issues by allowing the clock to be discontinuous, which might be beneficial in scenarios where the signal path is longer or more prone to interference. However, it’s crucial to ensure that this setting is compatible with the IMX477 sensor and the specific use case. The provided context does not explicitly mention the safety or effects of changing this setting for the IMX477, so it should be approached with caution and ideally verified against the sensor’s datasheet or manufacturer’s recommendations.

  2. Reducing pix_clk_hz: Lowering the pixel clock frequency (pix_clk_hz) can indeed reduce the CSI rate, potentially making the signal more tolerant to longer cable lengths or signal degradation. However, the valid values for pix_clk_hz depend on the sensor’s capabilities and the specific mode of operation (e.g., resolution and framerate). For the IMX477 in 1080p mode, the context does not provide specific alternative clock frequencies. Typically, sensor datasheets specify the supported clock ranges or discrete clock configurations for different modes. Reducing pix_clk_hz must be done in accordance with the sensor’s specifications to avoid incompatible settings that could lead to failure or reduced image quality.

  3. Other parameters for improving tolerance: Parameters like cil_settletime, deskew, or settle settings can be relevant for adjusting the camera’s or receiver’s timing to better match the signal characteristics over a longer cable. These adjustments can help in compensating for signal skew or settling time issues that might arise due to the extended cable length. However, the specific values or adjustments depend on the sensor, the receiver (in this case, the Jetson Orin Nano), and the cable characteristics. The provided context does not offer detailed guidance on these parameters for the IMX477 and Jetson Orin Nano combination.

Given the information and the constraints of the provided context, the most direct approach to improving the CSI signal tolerance over the longer path involves:

  • Consulting the IMX477 sensor datasheet for supported pixel clock frequencies and clocking schemes to determine safe and compatible settings for reducing the CSI rate.
  • Experimenting with discontinuous_clk = yes if supported by the sensor and ensuring this change does not adversely affect the system’s performance or compatibility.
  • Adjusting other timing parameters based on the sensor’s and system’s capabilities, ideally with reference to technical documentation or support from the manufacturers.

Without specific details on the sensor’s capabilities, the Jetson Orin Nano’s compatibility, or further technical documentation, these steps are generalized recommendations based on the principles of signal integrity and camera interface configuration.

— We support team will also look into your issue to have further suggestions soon. please stay tuned. —

Using gmsl or serdes design to enhance the length could be the right way.

Thanks