IMX519 camera capture hangs on Jetson Orin Nano (JetPack 6.2)

Nvidia Jetson Cameras
1

Hey everyone, I’m struggling to get the ArduCAM IMX519 working on my Jetson Orin Nano DevKit (P3768-0000 + P3767-0005). Running JetPack 6.2 with L4T R36.4.7, kernel 5.15.148-tegra.

I installed the driver using install_full.sh -m imx519 and the camera does show up on I2C — I can see it on bus 9 at 0x1a. /dev/video0 is created and all the expected sensor modes are listed:

RG10 Bayer: 4656x3496@9fps, 3840x2160@17fps, 1920x1080@60fps, 1280x720@120fps

GPIO reset lines are PH.06 (line 49) and PAC.00 (line 138). nvargus-daemon is running. Boot config uses the arducam Image and the dual IMX519 overlay (tegra234-p3767-camera-p3768-imx519-dual.dtbo).

But any time I try to stream, I’m getting MIPI CSI-2 timeout errors. The kernel log is full of buffer failures. Has anyone seen this before with the IMX519 on Orin Nano?

2

Thanks for the detailed report. That’s an odd one — the I2C detection and mode enumeration both look healthy, which means the sensor is responding at the register level but the CSI data path isn’t flowing.

Let’s start with the basics. Can you try restarting nvargus-daemon and then test with a simple v4l2-ctl capture? Also, have you tried toggling the GPIO reset lines manually before streaming? Sometimes the sensor gets into a weird state and needs a proper reset cycle.

3

Yeah, I already tried restarting nvargus-daemon:

sudo systemctl restart nvargus-daemon

No change. I also manually toggled both GPIO lines (PH.06 and PAC.00), still the same timeouts.

I then tried setting a lower resolution with v4l2-ctl:

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=RG10

Same result. I also tested both bypass_mode settings:

v4l2-ctl -c bypass_mode=0 --stream-mmap --stream-count=2 -d /dev/video0
v4l2-ctl -c bypass_mode=1 --stream-mmap --stream-count=2 -d /dev/video0

Both modes fail with the CSI timeout. It’s like the data lanes just never start clocking.

4

Interesting. The bypass_mode tests suggest the issue is at the NVCSI level, not in the ISP pipeline. Before diving deeper into the hardware side, a few more things to check:

What does your device tree say for the tegra_sinterface and lane_polarity values? Also, can you try forcing the NVCSI and VI clocks to their max rates via debugfs? I’ve seen cases on R36 where the clock tree doesn’t ramp up correctly for certain sensor profiles.

The commands would be:

sudo su -c ‘echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked’
sudo su -c ‘cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate’

Do that for nvcsi, vi, and isp clocks, then try streaming again.

5

Good call on the clocks. I locked all three (nvcsi, vi, isp) to max rate via debugfs and tested again — same timeouts unfortunately.

I also tried inserting a queue element in GStreamer just in case it was a downstream processing bottleneck:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! queue ! fakesink

Still fails. The CSI timeout happens almost immediately, so it doesn’t seem like a buffering or pipeline scheduling issue.

One more thing I tried: I cleared the ISP configuration caches and restarted nvargus-daemon:

sudo rm /var/nvidia/nvcam/settings/camera_overrides.isp
sudo rm -rf /var/nvidia/nvcam/settings/serial_no_*
sudo systemctl restart nvargus-daemon

No luck there either.

6

Okay, let’s look at the device tree side then. Can you check what tegra_sinterface is set to in your overlay? For the IMX519 on the Orin Nano DevKit, it should typically be serial_c for CAM0. Also what’s your lane_polarity set to? The default is usually “6” but some configurations need “0”.

Worth also mentioning: have you tried both CSI ports? CAM0 (J20) and CAM1 (J21)?

7

I changed tegra_sinterface to serial_c and lane_polarity from “6” to “0” — rebuilt and redeployed the DTB. No difference.

And yes, I’ve tested on both CAM0 (J20) and CAM1 (J21). Same failure on both ports.

At this point I started wondering if it was a software version issue, so I went down a bit of a rabbit hole:

  • Upgraded nvidia-l4t packages to 36.4.7
  • Downgraded to 36.4.4
  • Tried selectively holding kernel packages at different versions

None of that helped. So I went nuclear and did complete system reflashes — Balena Etcher, SDK Manager, even the flash.sh script directly. Tested JetPack 6.1, 6.2, and 6.2.1. All produce exactly the same MIPI CSI-2 timeout.

8

That’s a lot of ground covered. The fact that it persists across three JetPack versions rules out a kernel regression. Let’s shift focus to hardware.

You mentioned the I2C side works fine — can you confirm you’ve tried:

  • Different 22-pin CSI ribbon cables? (0.5mm pitch)
  • Multiple IMX519 camera modules?
  • Any other camera models on this same DevKit?

Also, do you have access to another Jetson Orin Nano DevKit to test these same cameras on?

9

Yep, I’ve been pretty thorough on the hardware side:

  • Tried 3 different 22-pin 0.5mm pitch CSI ribbon cables — all same result
  • Tested 2 different IMX519 modules — both fail identically
  • Also tried an IMX219 and an AR0234 Jetvariety on this board — they fail too
  • Tested on a second Orin Nano DevKit board — same errors

But here’s the kicker: all these cameras (IMX519, IMX219, AR0234) work perfectly on a third Jetson Orin Nano DevKit that a colleague has, running the same JetPack version. So the cameras and cables are definitely good.

I’m kind of stumped. Two DevKits, both fail. A third one works fine. What else could be different between these boards?

10

That’s actually a really useful data point. The fact that multiple camera models fail on two boards but work on a third, with identical software, strongly points to a hardware-level difference on those specific DevKits.

Can you share some detailed logs? Specifically:

  • Full kernel dmesg (especially the tegra-camrtc-capture and nvcsi entries around the timeout)
  • GStreamer debug output with GST_DEBUG=*:3 or higher
  • nvargus-daemon logs
  • The exact device tree you’re using

The MIPI CSI-2 timeout pattern can sometimes reveal whether it’s a lane mapping issue, a clock routing problem, or a signal integrity problem on the board itself.

Also — this might sound odd — but could you post clear photos of the top and back of one of the failing DevKits? Sometimes there are board revision differences or visible component issues that don’t show up in software.

11

I’ve uploaded the full system report with dmesg, GStreamer traces, nvargus-daemon logs, and the device tree. The dmesg shows the typical pattern:

tegra-camrtc-capture: MIPI CSI-2 stream timeout
nvcsi: error on stream capture

Followed by buffer release failures. It’s pretty consistent across all resolutions and both ports.

I’ve also sent the board photos in a private message — didn’t want to clutter the thread with large images. But honestly, both boards look physically identical to the working one as far as I can tell. Same P3768-0000 carrier, same P3767-0005 module, same revision markings.

One thing I haven’t mentioned — I also tried the Jetson_IMX519_Focus_Example repo from ArduCAM’s GitHub, just to rule out a userspace issue. Same result.

12

Thanks for uploading everything. I’ve reviewed the logs and the photos. The dmesg pattern you’re seeing — immediate CSI timeout with no data flowing at all — really does point to a physical layer problem rather than a driver or configuration issue.

Given that:

  • I2C works fine (sensor is alive and responding)
  • Sensor modes enumerate correctly
  • Multiple cameras fail on these two specific boards
  • The same cameras work on a third board
  • Multiple JetPack versions and full reflashes don’t help
  • Both CSI ports are affected on the failing boards

This is looking like a board-level signal path issue. Could be the MIPI CSI termination, the clock routing between the module and carrier, or something in the Tegra CSI PHY initialization that only manifests on certain board revisions.

At this stage I think we need to do a more interactive debugging session. I’ve sent you the remote access details via private message — if you’re up for it, we can schedule a live session and I’ll take a direct look at the register state and signal diagnostics on one of the failing boards. There are some low-level Tegra CSI debug interfaces I’d like to probe that aren’t easy to walk through over forum posts.