Page 2 · How it works
CSI-2 Protocol
Everything above the PHY: how pixels or samples become bytes, how bytes become packets, and how packets are spread across lanes and reassembled.
The layers in order
- Pixel-to-byte packing. The sensor's samples are packed into bytes according to the data type. RAW8 is one byte per pixel. RAW10 packs four pixels into five bytes: the four upper 8-bit parts, then one byte holding the four 2-bit remainders. RAW12 packs two pixels into three bytes.
- Low-level protocol. Bytes are wrapped in packets. Each packet has a header with an ECC, and long packets carry a CRC.
- Lane management. The packet's bytes are striped round-robin across 1, 2, 3 or 4 data lanes.
- PHY. Each lane serializes its bytes LSB first and sends them in high-speed bursts.
Packets
There are two kinds. A short packet is four bytes: a Data Identifier, a 16-bit data field, and an ECC byte. Short packets mark structure: Frame Start, Frame End, Line Start, Line End, and generic short packets for things like shutter sync. A long packet has the same 4-byte header, where the 16-bit field becomes the Word Count (WC), the number of payload bytes. After the payload come two CRC bytes.
| Field | Size | What it does |
|---|---|---|
| Data Identifier (DI) | 8 bits | Virtual Channel in bits 7:6 (0–3 in v1.x), Data Type in bits 5:0. |
| Word Count / data field | 16 bits | Long packet: payload length in bytes, LSB first. Short packet: frame number (FS/FE) or line number (LS/LE), or 0 if unused. |
| ECC | 8 bits | Six Hamming parity bits over the 24 header bits. Corrects any single-bit error and detects two-bit errors. In v2.0 the two spare bits extend the virtual channel field (VCX). |
| Payload | WC bytes | The packed data. Not covered by the ECC. |
| Packet footer | 16 bits | CRC-16 over the payload, polynomial x¹⁶ + x¹² + x⁵ + 1, seeded 0xFFFF. Detects, does not correct. |
Why the split between ECC and CRC: a corrupted header is fatal, because the receiver would use the wrong word count and lose sync for the rest of the burst. So the header gets correction. A corrupted payload only spoils that one line, so detection is enough, and the line is flagged or dropped.
Frames and lines
The receiver rebuilds the image structure from short packets. Frame Start and Frame End carry a frame number that increments by one each frame (1, 2, 3…, wrapping) or stays 0 if the sensor doesn't count. Line Start and Line End are optional. Many sensors leave them out and let the long packet itself mark the line. Between packets the lanes return to LP-11; that idle time is the horizontal and vertical blanking.
On D-PHY, the spec separates packets by an EoT, a period in low-power state, and a new SoT. Each line therefore costs a fixed LP↔HS turnaround overhead of a few hundred nanoseconds on top of its payload time. At high line rates that overhead sets a practical floor on line time.
Data types
| DT code | Name | Notes |
|---|---|---|
| 0x00 / 0x01 | Frame Start / Frame End | Short. Data field = frame number. |
| 0x02 / 0x03 | Line Start / Line End | Short, optional. Data field = line number. |
| 0x08–0x0F | Generic short packets | Sensor-defined events. |
| 0x10 / 0x11 | Null / Blanking | Long packets the receiver discards. |
| 0x12 | Embedded 8-bit non-image data | Sensor status lines, often sent before or after the image lines. |
| 0x18–0x1F | YUV formats | YUV420, YUV422 in 8 and 10 bit. |
| 0x20–0x24 | RGB444 to RGB888 | |
| 0x28–0x2D | RAW6, RAW7, RAW8, RAW10, RAW12, RAW14 | Bayer data straight from the pixel array. 0x2B RAW10 is the most common. |
| 0x2E / 0x2F | RAW16 / RAW20 | Added in v2.0. |
| 0x30–0x37 | User-defined 8-bit | Opaque bytes. A common choice for non-camera payloads such as radar samples. |
The receiver uses the data type for two things: to unpack bytes back into samples, and to route packets. A receiver that only understands camera types will still pass user-defined or RAW8 packets through as raw bytes, which is how non-image data rides on camera hardware.
Virtual channels
The 2-bit VC field lets up to four logical streams share one physical link. The receiver demultiplexes by VC. Typical uses: several exposures of an HDR sensor, an image stream plus a metadata stream, or four cameras aggregated by a deserializer onto one CSI-2 port. VC and data-type interleaving can happen at packet granularity, so a frame on VC0 can be interrupted by a line on VC1. v2.0 extended the VC field to 16 channels on D-PHY using the VCX bits.
Lane distribution
Each lane does its own start of transmission, so each lane also has its own sync byte to find. Lanes can arrive a few UI apart because of trace skew. The receiver's lane aligner waits until every lane has found sync, then interleaves bytes back in order. If the packet length (4 + WC + 2) is not a multiple of the lane count, the last lanes end one byte early. The receiver knows this from the word count, and discards whatever trail bits follow.
Control: CCI
CSI-2 has no back channel on the data lanes. The host configures the sensor over CCI, a two-wire bus compatible with I²C fast mode (400 kHz), with the host as master. Image sensors expose a register map there: exposure, gain, windowing, lane count, PLL settings. Newer revisions allow I3C. Not every CSI-2 transmitter uses CCI. The AWR2243, for example, is configured over SPI with TI's mmWaveLink commands, and only its data path is CSI-2.
Revisions in brief
| Version | Main additions |
|---|---|
| v1.0–v1.1 | Base protocol on D-PHY: 4 VCs, RAW/YUV/RGB types, ECC and CRC. |
| v1.3 | C-PHY added as a second PHY option. |
| v2.0 | RAW16 and RAW20, virtual channel extension (VCX), optional scrambling to spread spectral peaks for EMI. |
| v3.0 and later | Unified Serial Link (control over the data link), RAW24, region-of-interest features, always-on low-power sensing modes. |
Questions to expect
Why does the header get ECC but the payload only a CRC?
The header tells the receiver how many bytes to expect. If the word count is wrong, the receiver misframes everything after it until the next SoT. Correcting single-bit errors there keeps the link in sync. A payload error only affects one line, so detecting it with a CRC and dropping the line is enough.
How does the receiver know where a packet ends on each lane?
From the word count in the header. Each lane's EoT is followed by trail bits that hold the inverse of the last data bit. They look like data, so the receiver must stop by count and ignore them.
Can you send non-image data over CSI-2?
Yes. Use a user-defined data type (0x30–0x37), a generic long packet, or RAW8, and treat the payload as opaque bytes. Radar ADC streams and ToF depth data travel this way. The catch is that the host's receiver and driver have to accept a format that isn't a known pixel format.
What happens on a CRC error?
Nothing at the link level. There is no retransmit. The receiver flags the line, and the application decides whether to drop the line, the frame, or keep it. For radar, a bad chirp corrupts the Doppler FFT for that frame, so the usual choice is to drop the frame and count the event.