Jetson Orin Nano – capture timeout vs. long STREAMOFF delay (GPIO FSYNC / PWM)

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hi,
Jetson Orin Nano (JP 6.2, kernel 5.15.148‑tegra), using the VI driver (tegra-camrtc-capture-vi / vi5_fops.c).

We use two FSYNC modes:

  1. GPIO trigger: we manually pulse FSYNC
  2. PWM trigger: FSYNC is toggled continuously by PWM

Issue:

  1. With the default 2500 ms timeout, if we STREAMON and then wait longer than 2.5 s before the first FSYNC pulse (GPIO mode), the driver logs the below shown timeout, resets the capture channel, and frames received are invalid.

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
tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel

  1. If we raise the timeout (e.g. 30 s) to avoid that reset, VIDIOC_STREAMOFF then blocks for the full timeout for both GPIO and PWM mode.

What we want:

  1. No auto‑reset just because FSYNC is late.
  2. STREAMOFF should return quickly (sub‑second), regardless of the capture timeout.

Questions:

  1. Is there a supported way (control, module param, recommended sequence) to keep a large capture timeout but have a short STREAMOFF delay?

Any advice appreciated. Thanks!

2

*** Please note that this reply is generated by LLM automatically ***

The question revolves around the Jetson Orin Nano platform, specifically focusing on issues related to the VI driver, FSYNC modes (GPIO trigger and PWM trigger), and timeout settings for capture channels. The problem arises when the default timeout of 2500 ms is exceeded before the first FSYNC pulse is received, leading to the capture channel being reset and resulting in invalid frames. The user seeks a way to maintain a large capture timeout without triggering an autoreset, allowing for a quick return (subsecond) regardless of the capture timeout.

Understanding the Issue

  1. VI Driver and FSYNC Modes: The VI (Video Input) driver is used for capturing video streams on the Jetson platform. FSYNC (Frame Synchronization) is crucial for synchronizing the capture of frames. The user is employing two FSYNC modes: GPIO trigger, where FSYNC is manually pulsed, and PWM (Pulse Width Modulation) trigger, where FSYNC is continuously toggled by PWM.

  2. Timeout Issue: The default timeout of 2500 ms (2.5 seconds) is too short for the application. When this timeout is exceeded before the first FSYNC pulse, the driver logs a timeout error, resets the capture channel, and any frames received are invalid.

  3. Desired Behavior: The user wants to avoid the autoreset of the capture channel due to late FSYNC pulses. Instead, the system should return quickly (in less than a second) without resetting the capture channel, even if the capture timeout is large.

Possible Solutions and Recommendations

  1. Adjusting Timeout Values: One straightforward approach is to increase the timeout value to accommodate the delay before the first FSYNC pulse. However, this has been tried (e.g., setting the timeout to 30 seconds), and it leads to the system blocking for the full timeout period in both GPIO and PWM modes, which is undesirable.

  2. Module Parameters and Sequence: The user is looking for a supported way to control module parameters or a recommended sequence that allows for a large capture timeout without triggering an autoreset. This might involve modifying the device tree configuration or adjusting kernel parameters related to the VI driver and FSYNC handling.

  3. Customizing the VI Driver: Depending on the flexibility of the VI driver and the specific requirements of the application, customizing the driver to handle FSYNC pulses and timeouts differently might be necessary. This could involve modifying the driver’s source code to introduce a new timeout parameter specifically for the FSYNC pulse detection or to implement a more sophisticated timeout handling mechanism that distinguishes between different types of timeouts (e.g., capture timeout vs. FSYNC pulse detection timeout).

  4. Utilizing Interrupts and GPIO Configuration: Given the involvement of GPIO triggers, exploring the configuration of GPIO pins and interrupt handling might offer a solution. Properly configuring interrupts and possibly utilizing the SIPL (Sensor Interface Programming Library) platform configuration for GPIO and interrupt localization could help in achieving the desired behavior without extensive modifications to the VI driver.

Comparative Analysis

  • Jetson Orin Nano vs. Other Jetson Modules: The issue at hand seems specific to the Jetson Orin Nano’s configuration and the VI driver’s behavior on this platform. Comparatively, other Jetson modules like the Xavier NX or the Jetson AGX Orin series might handle timeouts and FSYNC pulses differently, either due to variations in hardware capabilities or differences in driver implementations.

  • Software vs. Hardware Solutions: The solution might involve either software modifications (e.g., adjusting kernel parameters, customizing the VI driver) or hardware configurations (e.g., adjusting GPIO configurations, using external components to manage FSYNC pulses). A purely software-based solution would be preferable for ease of implementation and flexibility across different hardware setups.

Conclusion

To achieve the desired behavior of maintaining a large capture timeout without autoresetting the capture channel due to late FSYNC pulses, the user may need to explore a combination of adjusting module parameters, customizing the VI driver, and optimizing GPIO and interrupt configurations. Given the complexity and specificity of the issue, consulting the official NVIDIA Jetson forums, documentation, or seeking support from NVIDIA’s developer community might provide more targeted advice or patches that address this particular requirement.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

hello srivatsan.ravichandran,

I do not understand this.. why increasing timeout setting leads to the system blocks.
please refer to VI kernel driver, it’s calling V4L2 driver framework to stream-off.
for instance,
$public_sources/kernel_src/kernel/nvidia-oot/drivers/media/platform/tegra/camera/vi/channel.c

static const struct v4l2_ioctl_ops tegra_channel_ioctl_ops = {
...
        .vidioc_streamoff               = vb2_ioctl_streamoff,

or..
do you have any logs for reference?