Camera issues on Jetpack 6.2.1, L4T 36.4.7

We currently have a system running on Jetpack 6.1 and I am trying to upgrade the system to Jetpack 6.2.1 for the better packaages and higher power modes. I have managed to port my camera drivers and the app to 6.2.1 But if I leave the camera to run overnight the, I will come back and see the stream is frozen and I will have to power cycle to refresh the camera and get an output again. Any idea how to fix this?
Im running this on a Jetson Orin NX

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

Based on the provided context, I’ll offer a comprehensive answer to the question.

The issue you’re experiencing with the camera stream freezing on Jetson Orin NX after upgrading to Jetpack 6.2.1 might be related to several factors. Since you’ve managed to port your camera drivers and app to Jetpack 6.2.1, let’s focus on potential causes and solutions:

  1. Power management: Jetpack 6.2.1 introduces new power modes for Jetson Orin NX, which might affect the camera’s behavior. Ensure that you’re using the correct power mode for your application. You can try setting the power mode to MAXN SUPER, which is the highest power mode available for Jetson Orin NX 8GB and 16GB modules.
  2. Camera driver: Although you’ve ported your camera drivers to Jetpack 6.2.1, there might be issues with the driver’s compatibility or configuration. Verify that the camera driver is correctly configured and that there are no errors in the kernel logs (dmesg). You can also try updating the camera driver to the latest version available for Jetpack 6.2.1.
  3. System resource management: The freezing issue might be related to system resource management, such as memory or CPU usage. Monitor the system’s resource usage using tools like top, htop, or sysdig to identify potential bottlenecks. You can also try adjusting the system’s resource allocation to prioritize the camera application.
  4. Thermal management: Jetson Orin NX has a thermal management system that might throttle the CPU or GPU if the system temperature exceeds a certain threshold. Check the system’s temperature using tools like sensors or nvidia-smi to ensure that it’s within a safe range. You can also try adjusting the thermal management settings to prevent throttling.
  5. Firmware issues: Firmware issues can cause the camera to freeze or malfunction. Ensure that the camera’s firmware is up-to-date and compatible with Jetpack 6.2.1.

To troubleshoot the issue, you can try the following:

  • Check the kernel logs (dmesg) for any error messages related to the camera or system resources.
  • Monitor the system’s resource usage using tools like top, htop, or sysdig.
  • Verify that the camera driver is correctly configured and that there are no errors in the kernel logs.
  • Try setting the power mode to MAXN SUPER to ensure that the system is running at its highest performance level.
  • Update the camera driver to the latest version available for Jetpack 6.2.1.

If none of these solutions resolve the issue, you may want to consider seeking further assistance from NVIDIA’s support forums or the Jetson developer community.

Comparison with other Jetson modules:

  • Jetson Orin Nano: This module has similar power management features to Jetson Orin NX, but it has a different camera interface (MIPI CSI-2). If you’re experiencing similar issues on Jetson Orin Nano, you can try the same troubleshooting steps.
  • Jetson AGX Orin: This module has a different power management system and camera interface (MIPI CSI-2) compared to Jetson Orin NX. If you’re experiencing similar issues on Jetson AGX Orin, you may need to consult the specific documentation and troubleshooting guides for that module.

In summary, the freezing issue on Jetson Orin NX after upgrading to Jetpack 6.2.1 might be related to power management, camera driver, system resource management, thermal management, or firmware issues. By troubleshooting these potential causes and adjusting the system’s configuration, you should be able to resolve the issue and achieve stable camera performance.

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

hello amaharaj1,

please share your reproduce steps, and also the logs for reference.

besides.. if that’s possible, please try moving forward to JetPack 6.2.2/r36.5.0
it’s the latest JP-6 release version which also include some PSIRT fixes. see-also.. r36.5 Release Notes.

hello amaharaj1,

BTW, there’re some JP-6.2.1 bug fixes.
please give it a try to apply below two patches, which might related to your frozen stream issue.
– Topic 325399: kernel memory leak when using Argus camera
– Topic 337609: VI memory leakage fix with error recovery.

  • Platform:

    • Jetson Orin NX on Seeed reComputer J401 carrier.
    • JetPack 6.2.1 / r36.4 stack.
    • Kernel 5.15.148-tegra.
    • Target reports L4T 36.4.7 in jtop, although public JP6.2.1 docs refer to 36.4.4.
  • Camera hardware:

    • e-con Systems e-CAM24 / AR0234.
    • Final working node: vi-output, ar0234 9-0042.
    • Camera appears as /dev/video0.
  • Starting issue:

    • The AR0234 .dtbo existed on disk, but the overlay was not actually applying.
    • Runtime symptoms were:
      • no /dev/video*
      • no /dev/v4l-subdev*
      • no /dev/i2c-9 or /dev/i2c-10
      • no live DT nodes for cam_i2cmux, tegra-camera-platform, or ecam_ar0234_*@42.
  • Driver/overlay base:

    • Used the newer e-con r36.4 camera pack:
      • e-CAM24_CUONX_JETSON_ONX_36.4.4_16-DEC-2025_R01_RC1
    • This was better than trying to force the older r36.3.0 camera pack forward.
  • Main DT overlay problem:

    • The AR0234 overlay referenced this regulator:
      • &p3768_vdd_3v3_sys
    • The Seeed J401 r36.4 base DTB did not expose that symbol.
    • The equivalent available regulator label was:
      • &hdr40_vdd_3v3
    • fdtoverlay failed with FDT_ERR_NOTFOUND, confirming a missing overlay fixup/symbol.
  • Main fix:

    • Changed the AR0234 overlay supply from:
      • vcc-supply = <&p3768_vdd_3v3_sys>;
    • to:
      • vcc-supply = <&hdr40_vdd_3v3>;
    • Applied this in the AR0234 DTS and the local r36.4.4 e-con DTB patch.
  • Validation of fix:

    • After rebuilding the overlay, fdtoverlay successfully merged it into the Seeed J401 base DTBs:
      • tegra234-j401-p3768-0000+p3767-0001-recomputer.dtb
      • tegra234-j401-p3768-0000+p3767-0001-recomputer-super.dtb
  • Build issue encountered:

    • make dtbs initially tried to use host Ubuntu kernel headers:
      • /lib/modules/6.8.0-90-generic/build
    • Fixed by explicitly setting Jetson kernel paths:
      • KERNEL_HEADERS=top_dir/Linux_for_Tegra/source/kernel/kernel-jammy-src
      • KERNEL_OUTPUT=top_dir/Linux_for_Tegra/source/kernel/kernel-jammy-src
  • Required staging:

    • Copied the rebuilt AR0234 overlay to:
      • top_dir/Linux_for_Tegra/kernel/dtb/
      • top_dir/Linux_for_Tegra/rootfs/boot/
  • Required boot/flash config:

    • Added the AR0234 DTBO to OVERLAY_DTB_FILE in:
      • recomputer-orin-j401.conf
      • recomputer-orin-super-j401.conf
    • Added boot-time overlay reference in extlinux.conf:
      • FDT /boot/dtb/kernel_tegra234-j401-p3768-0000+p3767-0001-recomputer.dtb
      • OVERLAYS /boot/tegra234-p3767-0000-p3768-0000-a0-2lane-ar0234.dtbo
  • Runtime proof:

    • Live DT contained AR0234 nodes:
      • /bus@0/cam_i2cmux/i2c@0/ecam_ar0234_a@42
      • /bus@0/cam_i2cmux/i2c@1/ecam_ar0234_c@42
    • Device nodes appeared:
      • /dev/video0
      • /dev/v4l-subdev0
      • /dev/v4l-subdev1
      • /dev/v4l-subdev2
      • /dev/i2c-9
      • /dev/i2c-10
  • V4L2 result:

    • v4l2-ctl --list-devices showed:
      • vi-output, ar0234 9-0042
    • Supported UYVY modes included:
      • 640x480 @ 120 fps
      • 1280x720 @ 120 fps
      • 1920x1080 @ 65 fps
      • 1920x1200 @ 60 fps
  • Streaming proof:

    • Successfully captured 100 frames with:
      • v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=UYVY --stream-mmap --stream-count=100
    • Observed streaming around 62 fps.
    • Also confirmed visual image output after V4L2 validation.
  • Remaining note:

    • Some GStreamer preview tests failed because userspace NVIDIA multimedia/GStreamer packages were missing, e.g. no nvvidconv.
    • That appears to be a rootfs/package issue, not a kernel/DT/camera-driver issue.

hello amaharaj1,

we still need the logs for reference, you may setup a host with serial console to gather the UART logs continuously.

Ill post the logs in a bit would it be worth upgrading to Jpk 7.2 instead of troubleshooting 6.2.1

hello amaharaj1,

yes, please moving forward to JP-7.2
you should start a new discussion thread for following up, please also link this topic-id for reference.