## Summary
We have a 2-lane MIPI CSI-2 camera outputting UYVY 640x512 @ 60fps that works perfectly on a Jetson Orin NX (L4T 35.4.1, custom carrier board) but has frame boundary misalignment on the Jetson Orin Nano Developer Kit. Both use the same flircam V4L2 sensor driver (tegracam framework) and identical DTS mode parameters.
## Hardware
- **Camera:** Proprietary 2-lane MIPI CSI-2 thermal sensor
-
Output: UYVY (YUV422-8bit, CSI-2 DT 0x1E), 640x512 @ 60fps
-
MIPI DDR clock: 246 MHz, continuous clock mode
-
2 data lanes, D-PHY
- **Working platform:** Jetson Orin NX + custom carrier board, L4T 35.4.1, kernel 5.10.120
- **Broken platform:** Jetson Orin Nano 8GB Dev Kit (p3768-0000), L4T 36.5.0, kernel 5.15.185
## DTS Mode Parameters (identical on both platforms)
```
pix_clk_hz = “61500000”;
line_length = “642”;
active_w = “640”;
active_h = “512”;
csi_pixel_bit_depth = “16”;
dynamic_pixel_bit_depth = “16”;
mode_type = “yuv”;
pixel_phase = “uyvy”;
discontinuous_clk = “yes”;
cil_settletime = “20”;
num_lanes = “2”;
tegra_sinterface = “serial_b”;
lane_polarity = “6”;
embedded_metadata_height = “0”;
```
## Driver
Standard tegracam-framework sensor driver with stub callbacks (no register writes — camera is self-configured via I2C before streaming). The `start_streaming` and `stop_streaming` callbacks return 0 immediately. Power management is stubbed (camera is always powered).
## Symptom on Orin Nano (L4T 36.5.0)
GStreamer captures frames, but every frame shows **frame boundary misalignment**: approximately 3/4 of frame N followed by 1/4 of frame N+1. The VI appears to start its capture window mid-frame, not aligned to the camera’s SOF packet.
### dmesg errors:
```
tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 25683, flags: 0, err_data 131072
tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 25684, flags: 0, err_data 131072
```
- `err_data 131072` (0x20000) = CSIMUX_FRAME error on every frame
- No `err_rec` error recovery messages (unlike the working NX)
- Frame numbers increment (NVCSI IS receiving CSI-2 data)
- With VI/NVCSI clocks boosted to maximum, ~45% of frames pass through as “complete” but are still misaligned
### Analysis of captured frames:
- 100-frame capture: first ~50 frames are 74% filled (partial), later frames become 100% filled
- “100% filled” frames contain valid data but from 2 consecutive camera frames spliced together
- The splice point is consistent at ~384/513 lines (~75%)
## Behavior on Working Orin NX (L4T 35.4.1)
Same `corr_err` errors during startup, but the VI has `err_rec` error recovery:
```
corr_err: discarding frame 0, flags: 0, err_data 131072
err_rec: attempting to reset the capture channel
err_rec: successfully reset the capture channel
```
After several reset cycles, frames sync correctly and display a clean single image.
## What We’ve Tried
1. **pix_clk_hz tuning** (19.7M to 80M) — affects fill percentage but never eliminates misalignment
2. **Clock boosting** (VI=550MHz, NVCSI=214MHz) — improves fill from 17% to 45%
3. **discontinuous_clk = “no”** — worse results
4. **cil_settletime = “0”** (auto) — no improvement
5. **vc-id properties** — adding/removing makes no difference on L4T 36.x
6. **MIPI toggle** (disable MIPI → start pipeline → enable MIPI) — slight improvement but doesn’t fix alignment
7. **NV16 format** instead of UYVY — same 74% fill (format-independent)
8. **v1 vs v2 driver** (stub s_stream vs FSLP MIPI control) — same results
## Questions
1. Why does `err_rec` (error recovery with channel reset) occur on L4T 35.4.1 but NOT on L4T 36.5.0 for the same `corr_err` with `err_data 131072`?
2. Is there a DTS property or kernel parameter on L4T 36.x that enables the frame error recovery mechanism?
3. For a YUV422 camera with continuous MIPI clock and relatively slow pixel rate (~20 Mpixel/s effective vs 61.5 Mpixel/s MIPI link capacity), are there known NVCSI timing considerations on the Orin Nano?
4. Is the `pix_clk_hz` used by the VI for frame boundary detection, or only for exposure/framerate calculations? Our testing suggests it affects frame alignment, which contradicts the documentation stating it’s only for calibration.
## Environment
- **Working:** JetPack 5.1.2 (L4T 35.4.1), Orin NX, custom carrier, flircam driver (builtin)
- **Broken:** JetPack 6.2.2 (L4T 36.5.0), Orin Nano 8GB Dev Kit, flircam_boson640 driver (module)
- Both use tegracam framework, same sensor compatible string, same DTS parameters
Thank you for any guidance. @ShaneCCC @JerryChang
