jetsoncsi camerav4l2mipicamera driverdebugging

V4L2 uncorr_err on Jetson: what it means and how to fix it

Andres Campos ·

Key Insights

  • uncorr_err from tegra-camrtc-capture-vi means the NVCSI hardware is getting MIPI data it can’t decode — CRC/ECC errors at the physical layer
  • The sensor can be alive on I2C and /dev/video0 can exist while this error fires — probe success and capture success are completely independent
  • Five causes cover the vast majority of cases: wrong MCLK, MIPI link frequency mismatch, wrong lane count, lane polarity inversion on the PCB, power rail instability
  • Start with software (MCLK, link freq, lane count in DTS) before suspecting hardware — most cases are configuration, not board damage
  • Intermittent uncorr_err usually points to power; every-frame errors point to MCLK or lane misconfiguration

What uncorr_err actually means

When you see this in dmesg:

[  12.453] NVCSI stream 0, uncorr_err 0x00000001, err_status 0x00000020
[  12.454] tegra-camrtc-capture-vi 13e00000.vi: capture failed, err 0xffffffea
[  12.455] tegra-camrtc-capture-vi 13e00000.vi: vi_capture_control_message failed

…the sensor is producing MIPI output that the Jetson can’t decode. The NVCSI (NVIDIA CSI receiver) is getting data, but it’s garbage — CRC errors, lane alignment failures, or pure noise.

This is different from a probe failure. /dev/video0 exists because the sensor registered on I2C and V4L2 successfully. The driver ran through its initialization sequence. But the MIPI physical link between sensor and SoC is either misconfigured or broken.

Here’s the failure sequence: sensor starts streaming → MIPI data flows → NVCSI tries to receive and decode → data doesn’t match expected framing → uncorr_err → VI captures nothing → v4l2-ctl --stream-mmap returns zero bytes.

Root cause 1: wrong MCLK frequency

The sensor master clock (MCLK) drives the sensor’s internal PLL. If MCLK is wrong, the sensor’s output bit rate is wrong, and the NVCSI can’t lock onto it.

Most sensors have a very specific MCLK requirement. The IMX477, for example, uses a 24 MHz MCLK. Running it at 25 MHz (or at the default Tegra MCLK output if the DTS isn’t configured) will cause the sensor to output a different MIPI frequency than expected, producing uncorr_err.

Check your DTS sensor node:

mclk_khz = "24000";        /* Must match sensor datasheet */
mclk_multiplier = "2.0";   /* Check sensor PLL tables */

And verify the actual clock output on the MCLK pin with an oscilloscope if you have one. The Tegra clock divider arithmetic can produce frequencies that are slightly off if the parent clock isn’t what you assumed.

This is the most common cause on custom boards. The link_frequency in your sensor DTS must exactly match the MIPI bit rate the sensor is configured to output.

Example DTS entry:

link_frequencies = /bits/ 64 <456000000>;  /* 456 MHz per lane */

If the sensor is outputting 480 MHz per lane because a register write in the init sequence put it in a different mode, uncorr_err is inevitable. The NVCSI configures its receiver to expect the declared frequency and will desync if the actual frequency is different.

How to check: review your sensor initialization sequence against the datasheet. Sensors often have multiple output modes; verify the register values in your driver’s mode table correspond to the frequency declared in the DTS. A 5–10% mismatch will still cause errors.

Root cause 3: wrong lane count or polarity

The num_lanes in your DTS must match the actual number of MIPI CSI data lanes connected on the board. If you declare 4 lanes but only 2 are routed, or declare 2 lanes when the sensor is outputting 4, the NVCSI will either receive incomplete data or try to read lanes that have nothing on them.

num_lanes = "4";     /* Must match PCB routing */

Lane polarity is a separate issue. MIPI differential pairs have a defined P/N orientation. If your PCB routing inverted one or more pairs (swapped + and -), the NVCSI receives bit-inverted data on that lane. Every byte is corrupted. This produces uncorr_err on every frame.

On Orin, lane polarity inversions can be corrected in the device tree without board rework:

lane_polarity = "6";   /* Bitmask: bit N inverts lane N */

The bitmask encoding is in the Orin technical reference manual. You can determine which lanes are inverted by process of elimination if you don’t have board layout access.

Root cause 4: sensor power instability

The sensor needs clean, stable power rails during MIPI streaming. If VDD, VDDIO, or VANA is noisy or drops below spec during the sensor’s active imaging period, the MIPI transmitter output becomes intermittently corrupted.

uncorr_err caused by power issues often shows up as intermittent failures — some frames capture fine, others produce errors. Pure configuration issues (wrong MCLK, wrong link freq) produce errors on every frame.

Diagnostic steps:

  • Probe the sensor power rails with an oscilloscope during capture — look for voltage droop under load
  • Check if the errors go away when running at a lower frame rate (lower frame rate = lower average current draw)
  • Verify your camera VDD regulator has adequate current budget for the sensor + MIPI I/O

Root cause 5: incomplete sensor initialization

The sensor I2C init sequence must fully complete before the sensor starts streaming MIPI data. If a register write fails silently, or if the sequence is in the wrong order, the sensor may start transmitting before its internal PLL has locked.

Signs of this: uncorr_err on the first few frames only, or errors that go away when you add delays in the init sequence.

Check your driver’s sensor_reg_write calls for return values. A failed I2C write returns an error but many drivers log it as a warning and continue. If the sensor isn’t fully initialized, its MIPI output is undefined.

# Check for I2C errors during camera bring-up
sudo dmesg | grep -E "(i2c|I2C|sensor)" | head -30

Also check: does your driver implement s_stream in the right order? The sensor should not start MIPI output until after all mode registers are written and the PLL lock time has elapsed.

Diagnosis sequence

Work through these in order — start cheap, end with hardware:

  1. Verify MCLK: Check DTS mclk_khz against sensor datasheet. Measure on a scope if possible.
  2. Verify link frequency: Cross-reference DTS link_frequencies with the sensor init register table.
  3. Check lane count: Count the physical MIPI lanes on your schematic vs. DTS num_lanes.
  4. Check lane polarity: Review PCB layout for P/N swaps, or test with different lane_polarity values.
  5. Check sensor power: Probe rails during capture, lower frame rate to test.
  6. Add I2C error logging: Verify every init register write succeeds.

If all six check out and you’re still seeing uncorr_err, you may have a NVCSI configuration issue (PHY mode, T-PHY vs D-PHY selection) or an ESD-damaged MIPI receiver. At that point you’re into kernel trace-level debugging.

For the full CSI camera bring-up sequence, including how to structure your DTS and sensor driver for Orin, see our CSI camera driver on Jetson post. If your sensor also fails to produce frames after clearing the uncorr_err, see IMX sensor on Jetson: I2C detects but no frames for the next layer of diagnosis. If you’re hitting uncorr_err on a custom sensor and the standard fixes aren’t resolving it, book a scoping call — CSI bring-up is one of our most common engagements.

The MIPI CSI-2 specification covering CRC/ECC error handling is maintained by the MIPI Alliance. The Linux V4L2 subdev API documentation is at kernel.org.

Frequently Asked Questions

What does uncorr_err mean in Jetson dmesg?

uncorr_err is an uncorrectable CRC/ECC error from the NVCSI (NVIDIA CSI receive) hardware. It means the Jetson’s CSI receiver is getting MIPI data it cannot decode correctly — the data is corrupted before it reaches the VI pipeline. The camera may be detected on I2C and /dev/video0 may exist, but capture fails.

Why does /dev/video0 exist but capture fails with uncorr_err?

Device enumeration (I2C probe, V4L2 registration) happens independently from capture. A sensor can register on I2C and create /dev/video0 successfully, but still output corrupted MIPI data — from wrong MCLK, misconfigured lane parameters, or power issues. The uncorr_err is a capture-time failure, not a probe-time failure.

How do I check MIPI lane frequency on Jetson?

Check the link_frequency entry in your sensor driver’s DTS node or the V4L2 LINK_FREQ control. It must match the actual bit rate the sensor is configured to output. Mismatches of even a few percent cause uncorr_err. Use a scope or logic analyzer on the MIPI lanes to measure the actual frequency if you have doubts.

Can lane polarity inversions cause uncorr_err on Jetson?

Yes. If one or more MIPI data lanes have inverted polarity on the PCB (swapped P/N differential pairs), the NVCSI receives bit-inverted data and produces uncorr_err. Lane polarity can usually be corrected in the device tree using the lane_polarity bitmask without board rework.

Does uncorr_err always mean a hardware problem?

No. Most uncorr_err cases we fix are software configuration problems — wrong MCLK, wrong lane count, wrong link frequency in the DTS. Hardware issues do occur but are less common. Start with software diagnosis before assuming the board is bad.

ProventusNova specializes in CSI camera bring-up on Jetson. If uncorr_err is blocking your project, book a scoping call — this is one of our most common engagements.

← Back to Blog