IMX477 (B0249) — persistent CSI frame corruption (corr_err, err_data 8192) on both CAM0 and CAM1, JetPack 7.2 beta driver

1

Hardware:

  • Jetson Orin Nano, official NVIDIA dev kit carrier board
  • Camera: Arducam 12MP IMX477 (SKU B0249, 22-pin/TOP connector, CS mount)
  • JetPack 7.2 / L4T R39.2, kernel 6.8.12-tegra
  • Driver: arducam-nvidia-l4t-kernel (beta build 6.8.12-tegra-39.2.0-20260715155442, obtained from the official JetPack 7.2 beta driver forum thread)

Summary: After installing the beta driver, the camera is detected and initializes correctly at every layer up through ISP/NITO tuning — but every single captured frame is discarded due to a CSI-2 data integrity error. This is 100% reproducible, not intermittent, and occurs identically on both CAM0 and CAM1 with the same physical module.

What works:

  • dpkg -l confirms driver package installed cleanly
  • lsmod shows nv_imx477 and tegra_camera loaded
  • Device tree overlay applied correctly (tegra234-p3767-camera-p3768-imx477-dual.dtbo), NVCSI channels bind without dependency-cycle errors
  • I2C: sensor responds correctly at 0x1a on both bus 9 (CAM0) and bus 10 (CAM1); tegracam sensor driver:imx477_v2.0.6 loads, imx477_board_setup completes without error when working
  • GPU/nvgpu firmware: initially failed (ga10b_load_riscv_acr_ucodes: ucode get fail) due to firmware_class.path=/etc/firmware boot arg pointing to an empty directory — resolved by mirroring /usr/lib/firmware/nvidia/ga10b/acr-gsp* into /etc/firmware/nvidia/ga10b/. (This may be worth documenting/fixing in the installer — /etc/firmware is created empty but referenced in the kernel cmdline.)
  • Argus/libargus (nvargus-daemon, NVARGUS_DEBUG=1) loads NITO tuning correctly: imx477.nito found, BuildSensorModeInfoList correctly reports both sensor modes (3840x2160@30, 1920x1080@60)
  • /dev/video0 is created, v4l2-ctl --list-formats-ext and format negotiation succeed

What fails: Every capture attempt — via nvarguscamerasrc (GStreamer/Argus) or raw v4l2-ctl --stream-mmap (bypassing Argus/ISP entirely) — ends the same way:

Via Argus:

SCF: Error 0x0000000f: Error 15 Received for sensor 0 ..!
 (in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameEnd(), line 676)

(repeats until Argus gives up, INVALID_SETTINGS / “Argus Correctable Error Status” returned to GStreamer)

Via raw V4L2 (bypasses Argus/ISP layer completely):

tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 8192

This repeats continuously (~53ms interval) for as long as streaming is attempted — zero frames ever complete successfully, on either port.

Isolation steps taken:

  1. Confirmed identical failure on CAM0 and CAM1 with the same physical module (ruling out a single bad connector/port)
  2. Confirmed failure persists with raw V4L2 streaming, bypassing Argus/ISP/tuning entirely (ruling out an Argus-layer config/tuning bug — this is a kernel/PHY-level data integrity issue)
  3. Reseated CSI ribbon cable at both ends, checked orientation — no change
  4. GPU firmware issue (separate problem, described above) was fixed first and confirmed resolved (GStreamer pipeline reaches PLAYING, ISP pipeline reports capture setup complete) before this CSI corruption was isolated as the remaining blocker

Question:

  1. Is this a known issue with the current JetPack 7.2 beta build — specifically a D-PHY settle-time or lane-rate parameter that may need tuning for the 6.8.12 kernel’s CSI/VI driver stack? The consistent err_data 8192 on every frame (rather than an intermittent/partial corruption pattern) suggests a systematic timing misconfiguration rather than a marginal physical connection.
  2. Separately — I was initially told in [wherever you were told this] that the B0249 only supports the CAM1 port on Orin Nano, but your own documentation table here (Quick start - Arducam Wiki) lists imx477: cam0.cam1 Allowed. Could you confirm which is correct for this beta driver specifically?

Happy to provide full dmesg, NVARGUS_DEBUG=1 daemon output, or device tree dumps if useful. Let me know what additional diagnostics would help narrow this down — and if a hardware fault on this specific module is suspected, how to proceed with an RMA.

Thanks for the quick beta driver turnaround, by the way.