Jetson Camera Pipeline Microarchitecture Overview & Error Diagnosis
Introduction
When debugging video capture issues on NVIDIA Jetson platforms, there is often significant uncertainty about what the reported hardware errors actually mean or how they should be interpreted. In practice, many engineers end up searching through NVIDIA’s public forums looking for similar cases or indirect hints that might help resolve the problem. However, these errors originate from well-defined components inside the CSI/NVCSI microarchitecture, and most of them can be mapped directly to states, buffers, logic blocks, and interrupt flags described —although only partially— in the Technical Reference Manual (TRM).
The goal of this guide is to provide a high-level introduction to the Jetson CSI microarchitecture and to explain how to interpret common capture-related errors by mapping them back to the TRM, enabling faster and more informed debugging.
Distinction Between CSI, MIPI, and D-PHY
Before describing the Jetson CSI Microarchitecture subsystem, it’s important to clarify three terms that are often confused but represent different layers of the camera interface stack:
MIPI
- Refers to the industry consortium that defines many mobile interface standards.
- In camera contexts, “MIPI” typically means CSI-2 protocol operating over a D-PHY physical link.
- Not a protocol itself, just the umbrella under which the standards are defined.
D-PHY
- The physical layer that defines how bits travel electrically across differential lanes.
- Covers voltage levels, HS/LP modes, timing transitions, and serialization.
- Only transports bits; it does not understand frames, packets, or pixel formats.
CSI-2
- The protocol layer above D-PHY.
- Defines packet types, headers, ECC/CRC, virtual channels, and line/frame markers.
- Converts the raw bitstream into structured video data.
CSI Microarchitecture
NVIDIA does not publicly provide detailed microarchitecture documentation for the CSI/NVCSI subsystem in recent Tegra generations (TX2, Xavier, Orin). While the Technical Reference Manual (TRM) for these platforms includes functional descriptions and register overviews, it omits internal block diagrams, data paths, and lower-level implementation details. As a result, understanding how errors propagate through the CSI pipeline often requires inference, driver inspection, or comparison against historical architectures.
However, early Tegra platforms, most notably Tegra 2, included significantly more architectural detail in their public documentation. In particular, documents such as Tegra2_TRM_DP05282012v02.pdf (Please 
Download from here) contain extremely valuable diagrams and explanations of the CSI receiver path and including D-PHY front-end logic. Although the internal design of modern Jetson SoCs is more advanced and not identical to Tegra 2, the fundamental structure and processing stages remain conceptually very similar.
These legacy diagrams serve as a “window” into NVIDIA’s design philosophy for CSI: they describe the same types of components that still exist today (CIL logic, sync detection, lane deskew, asynchronous FIFOs, packet interpreters ) even if the exact implementation has evolved. By understanding the Tegra 2 microarchitecture, we can form a highly informed mental model of how modern NVCSI blocks behave internally, which in turn helps us map hardware errors and interrupt states to the underlying processing stages.
1. CSI Pad Block (Red Ones from the diagram)
The csia_pad block represents the physical entry point of the CSI interface on the SoC. It contains the D-PHY receivers for both the clock lane and the data lanes. Each element inside this block performs a specific role in recovering a clean, byte-aligned data stream from the incoming high-speed serial signaling.
Here’s what each component does:
1.1 D-PHY Receivers (Clock Lane & Data Lanes)
Each incoming MIPI lane, whether clock or data, first passes through a D-PHY receiver. At this stage, the hardware is focused purely on electrical-level signaling: recovering the high-speed bit clock from the clock lane, deserializing differential data on the data lanes, handling LP to/from HS mode transitions, and preserving timing integrity. The output of the D-PHY is a clean, stabilized bitstream, but it is not yet byte-aligned and carries no understanding of CSI-2 packets or higher-level structures.
1.2 Clock Divider (/4)
After the clock lane’s D-PHY, the signal passes through a clock divider that reduces the recovered high-speed bit clock to a stable byte clock used by the downstream logic. This divided clock ensures that all data lanes are sampled consistently and provides the timing reference required for correct bit-to-byte conversion.
1.3 SFT (Shift / Bit-to-Byte Logic)
Each data lane feeds into an SFT block, which is responsible for converting the raw serial bitstream into byte-aligned 8-bit words. Using the byte clock generated from the clock lane, the SFT groups bits into bytes, searches for the CSI-2 sync byte (0xB8) to establish proper alignment, and corrects for any initial offsets. This is the first stage where the bitstream gains structure: not full packets yet, but reliably aligned bytes that can be handed to CIL for packet boundary detection and further protocol-level processing.
2. How MIPI Describes the First Stages of Data Processing in a D-PHY Receiver
According to the MIPI D-PHY specification, a receiver must perform several well-defined steps before any CSI-2 packets can be interpreted.
The process begins with MIPI transition handshake. A camera sensor operates in two signaling modes: Low-Power (LP) and High-Speed (HS). The receiver monitors (NVIDIA Jetson SOC) the differential lines and recognizes the transition from LP to HS (specifically the LP-01 to LP-00 sequence) which indicates that the transmitter is about to send high-speed data. Once this transition is detected, the receiver enables its HS differential termination and prepares its analog front end. This process is described on MIPI Alliance Specification for D-PHY Section 5.4.2.
This diagram shows the MIPI Transition sequence from the transmitter’s view in a MIPI D-PHY interface.
Before any high-speed video data can be sent, the transmitter must follow a specific voltage-level sequence on the data lane (LP11-> LP01->LP00->HSO) for both the data positive lane (D_P) and data negative lane (D_N).
This sequence ensures that:
- the receiver recognizes the transition into High-Speed mode,
- the differential drivers are stable, and
- both sides are synchronized before real pixel data begins.
The D-PHY hardware (both TX and RX) is responsible for validating, timing, and enforcing this sequence. The real hardware signal looks like the following:
As you can see both data positive signal and data negative signal can be clearly identified on Fig 3 with all the stages of the SOT:
- LP-11: Both lines high; idle stop state before any transmission.
- LP-01: D+ low and D– high; transmitter requests transition to High-Speed mode.
- LP-00: Both lines low; bridge state where TX prepares HS drivers and RX enables termination.
- HS-Prepare / HS-Zero: TX turns on HS differential driver and holds a stable HS0 level while RX waits for signal to settle.
- SOT (Start-of-Transmission): TX sends sync pattern
00011101(Its always this pattern); RX detects and aligns byte boundaries. - HS-DATA: TX sends high-speed CSI-2 payload data; RX receives and processes aligned bytes.
- Return to LP Mode: TX switches back through LP-00 → LP-11; RX returns to idle detection.
3. Now can I use this information to debug from the software side
NVIDIA exposes a set of per CSI port interrupt and error registers in the NVCSI block so software can detect problems on the MIPI D-PHY physical layer without touching hardware tools like scopes or analyzers.
These registers reflect exactly what happened on each MIPI lane: alignment problems, SOT errors, deskew failures, FIFO overruns, etc.
You can use the following table to map each CSI port to each of the TRM debug registers:
| CSI Port | Commonly know as | TRM Register |
|---|---|---|
| CSI0 | CSI-A | NVCSI_PHY_0_CILA_INTR_0_STATUS_CILA_0 |
| CSI1 | CSI-B | NVCSI_PHY_0_CILB_INTR_0_STATUS_CILB_0 |
| CSI2 | CSI-C | NVCSI_PHY_1_CILA_INTR_0_STATUS_CILA_0 |
| CSI3 | CSI-D | NVCSI_PHY_1_CILB_INTR_0_STATUS_CILB_0 |
| CSI4 | CSI-E | NVCSI_PHY_2_CILA_INTR_0_STATUS_CILA_0 |
| CSI5 | CSI-F | NVCSI_PHY_2_CILB_INTR_0_STATUS_CILB_0 |
| CSI6 | CSI-G | NVCSI_PHY_3_CILA_INTR_0_STATUS_CILA_0 |
| CSI7 | CSI-H | NVCSI_PHY_3_CILB_INTR_0_STATUS_CILB_0 |
If you search for any of those registers on the Orin TRM document, you will find all of them follow the same structure:
The explanation of each register can be found on this table:
| Bit | Name | Meaning | |
|---|---|---|---|
| 30 | intr_cphy_clk_cal_done_trio1_b | C-PHY clock calibration done (trio 1). Not applicable to D-PHY sensors. | |
| 29 | intr_cphy_clk_cal_done_trio0_b | Same as above; safe to ignore for D-PHY. | |
| 28 | intr_dphy_cil_lane_align_err_b | Lane alignment failure. Could not align both lanes. One of the lanes might be off in time or completely dead. You could verify that with the oscilloscope. | |
| 27 | intr_dphy_cil_deskew_calib_err_ctrl_b | Deskew calibration failed at controller level. | |
| 26 | intr_dphy_cil_deskew_calib_err_lane1_b | Deskew calibration failed specifically on data lane 1. | |
| 25 | intr_dphy_cil_deskew_calib_err_lane0_b | Deskew calibration failed specifically on data lane 0 | |
| 24 | intr_dphy_cil_deskew_calib_done_ctrl_b | Deskew calibration finished (controller). | |
| 23 | intr_dphy_cil_deskew_calib_done_lane1_b | Deskew completed on data lane 1. | |
| 22 | intr_dphy_cil_deskew_calib_done_lane0_b | Deskew completed on data lane 0. | |
| 20 | intr_cil_data_lane_esc_mode_sync_err1_b | Escape-mode sync error on lane 1 — LP→ESC or ESC→LP sequence invalid. | |
| 19 | intr_cil_data_lane_esc_mode_sync_err0_b | Escape-mode sync error on lane 0. | |
| 10 | intr_cil_data_lane_sot_2lsb_err1_b | SOT 2-LSB mismatch on lane 1 — sync word partially corrupted. | |
| 9 | intr_cil_data_lane_sot_2lsb_err0_b | SOT 2-LSB mismatch on lane 0. | |
| 8 | intr_cil_data_lane_rxfifo_full_err1_b | RX FIFO overflow on lane 1 — data arrived faster than it could be consumed | |
| 7 | intr_cil_data_lane_ctrl_err1_b | Control error on lane 1: LP11→LP01→LP00 transition invalid. | |
| 6 | intr_cil_data_lane_sot_mb_err1_b | SOT multi-bit error on lane 1 — sync pattern severely corrupted. | |
| 5 | intr_cil_data_lane_sot_sb_err1_b | SOT single-bit error on lane 1 — first bits of sync damaged. | |
| 4 | intr_cil_data_lane_rxfifo_full_err0_b | RX FIFO overflow on lane 0. | |
| 3 | intr_cil_data_lane_ctrl_err0_b | Control error on lane 0 — invalid LP/HS sequence. | |
| 2 | intr_cil_data_lane_sot_mb_err0_b | SOT multi-bit error on lane 0. | |
| 1 | intr_cil_data_lane_sot_sb_err0_b | SOT single-bit error on lane 0. | |
| 0 | intr_dphy_cil_clk_lane_ctrl_err_b | Clock-lane control error — HS or LP transitions on the clock lane were invalid. |
note: bits 11-18 are nvidia reserved bits that can also appear on status, but no description is provided.
Practical Debug Example: Interpreting NVCSI D-PHY Errors in a Real Driver Failure
This section demonstrates how to analyze real NVCSI interrupt logs from a failing MIPI CSI-2 driver.
We apply the PHY/CIL mapping and the D-PHY error-bit definitions to understand exactly what went wrong, on which lane, and why.
1. Interrupt Logs Observed
A driver produced the following NVCSI interrupts:
kworker/1:1-56 [001] .... rtcpu_nvcsi_intr: class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 status:0x00001004
These represent two separate CIL receivers reporting different D-PHY errors. We know this because of the type of error called PHY_INTR.
2. Mapping the Errors to CSI Ports
Using NVIDIA’s PHY/CIL mapping and phy/cli data we got from the logs and Table 1 - CSI port to debug register map:
| NVCSI PHY | CIL | CSI Port Name | CSI Number |
|---|---|---|---|
| 1 (phy:1) | 0 (cil:0) | CSI-C | CSI2 |
This matches our hardware configuration:
- phy:1, cil:0 → CSI2 → data lane 0
So we know exactly which physical lane failed.
3. Decoding the Status Registers
Error: status: 0x00001004
Binary:
0000 0000 0000 0000 0001 0000 0000 0100
Bits set:
| Bit | Meaning | Lane | Interpretation |
|---|---|---|---|
| 2 | intr_cil_data_lane_sot_mb_err0 | 0 | Multi-bit SOT error on lane 0 (sync word severely corrupted). |
Lane 0 had severe SOT corruption. After confirming with the oscilloscope, we found that this lane presented signal integrity issues.
Other tips
PHY_INTR types
There are two kinds of PHY_INTR status:
global
kworker/0:4-164 [000] .... rtcpu_nvcsi_intr: class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x10000044
Correctable_err
kworker/0:4-164 [000] .... : rtcpu_nvcsi_intr: class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00001044
The globals error represent general error and the correctable_err represent errors that the driver can continue without exit due to the error. Correctable_err are not auto solved by the driver, they are just managed to avoid break the pipelines.
debug camera firmware.
NVIDIA can provide a camera debug firmware that include a little more information. Usually they provide them on forums.
https://forums.developer.nvidia.com/t/agx-orin-csi-e-port-4-support/320332/11?u=isaac.barrios
The extra information on trace logs appear as:
str:"tegra_nvcsi_stream_set_config(vm0, stream=2, csi=2)" str:"MIPI clock = 400000 kHz, tHS-SETTLE = 0, tCLK-SETTLE = 0" str:"===== NVCSI Stream Configuration =====" str:"stream_id: PP 2, csi_port: PORT C" str:"Brick: PHY 1, Mode: D-PHY" str:"Partition: CIL A, LP bypass: Enabled, Lanes: 4" str:"Clock information:" str:"MIPI clock rate: 400.00 MHz" str:"T_HS settle: 0, T_CLK settle: 0" str:"======================================" str:"tegra_nvcsi_stream_open(vm0, stream=2, csi=2)" str:"nvcsi_reset_data_lanes: NVCSI_PHY_1_NVCSI_CIL_A_" str:"SW_RESET_0 = 00000003" str:"nvcsi_reset_data_lanes: NVCSI_PHY_1_NVCSI_CIL_B_" str:"SW_RESET_0 = 00000003" str:"nvcsi_reset_lane_merger: NVCSI_PHY_1_LM_SW_RESET" str:"_0 = 00000001" str:"nvcsi_reset_lane_merger: NVCSI_PHY_1_LM_SW_RESET" str:"_0 = 00000000" str:"nvcsi_calc_ths_settle ths_settle 20" str:"nvcsi_calc_ths_settle ths_settle 20" str:"nvcsi_calc_ths_settle ths_settle 20" str:"nvcsi_calc_tclk_settle tclk_settle 33" str:"nvcsi_reset_data_lanes: NVCSI_PHY_1_NVCSI_CIL_A_" str:"SW_RESET_0 = 00000000" str:"nvcsi_reset_data_lanes: NVCSI_PHY_1_NVCSI_CIL_B_" str:"SW_RESET_0 = 00000000"
The debug firmware also make the PHY_INTR to appear on kernel messages as:
[ 2433.554846] [RCE] ISR PHY 1 CIL_A 0x10000044 [ 2433.554874] [RCE] ISR PHY 1 CIL_B 0x40
For direct inquiries, please refer to the contact information available on our Contact page. Alternatively, you may complete and submit the form provided at the same link. We will respond to your request at our earliest opportunity.
Links to RidgeRun Resources and RidgeRun Artificial Intelligence Solutions can be found in the footer below.
ARTIFICIAL INTELLIGENCE
