MIPI DSI Error Debugging: Separate CRC, ECC and Initialization Evidence

MIPI DSI error debugging starts with knowing which counter counts what, when it was sampled and what else changed. A display that occasionally shows a corrupted strip or a shifted block is often reported as a panel fault. The host may have counted errors for hours without anyone reading them, or the counters may have been cleared at every boot so the history disappeared. Error debugging starts with knowing which counter counts what, when it was sampled and what else changed at the same moment. This guide sets out a counter protocol, a rate sweep and a rail-correlation method that separate a marginal link from a command or initialization problem.

What do ECC and CRC counters in MIPI DSI error debugging distinguish?

ECC protects headers; CRC protects payload bytes.

ECC corrects a single-bit header error and flags more, while CRC detects payload corruption without correcting it, so the counters point to different locations.

DSI packets carry a header with error-correcting code and a payload with a cyclic redundancy check. The ECC is designed to correct a single-bit error in the header and to detect more than one, which protects the packet’s identity and length. The CRC covers the payload and detects corruption, but it does not correct it. A packet with a bad CRC is normally discarded.

That difference is diagnostic. An ECC error means the header was disturbed, which can happen on any lane or in the packet parser. A CRC error means the payload was disturbed, which points more strongly to the data path, the lane margin or a burst of interference. A rising CRC count with a stable ECC count suggests a payload-path problem; the reverse suggests a header or control-path problem.

Neither counter tells you the cause on its own. They tell you where to look. The next step is to establish when the errors occur and what else was happening at that moment.

When should counters be sampled and cleared?

Sample before clearing and record the interval.

Read counters at a known time, record the interval and traffic, then clear them; clearing without a timestamp destroys the rate information.

A counter value without a time base is hard to interpret. Ten errors during a ten-second boot may be a serious link problem; ten errors during a ten-hour soak may be a rare event that still matters but has a different priority. Record the sample time, the elapsed interval, the traffic pattern and the counter value before clearing.

Counters can saturate or wrap. If the width is narrow, a long soak without sampling can hide both the rate and the timing. Sample at an interval that keeps the expected count well below the maximum, and note the counter width. If the counter is already at its maximum, report a lower bound rather than a precise number.

Clearing should be deliberate and logged. Clearing at boot, or as part of a driver reset, erases the evidence that the previous session produced. If the product clears counters automatically, capture them before the clear and store the result in a diagnostic record. The DRM panel and bridge helpers describe the lifecycle around the panel and bridge, which is where the sampling hooks usually sit.

How do lane-rate changes help isolate margin?

A rate sweep separates margin from a hard fault.

If errors vanish at a lower rate and return at the intended rate, the link is marginal; if they persist at every rate, suspect wiring, clocking or initialization.

The lane rate is a controlled variable. Reducing it lowers the required bandwidth per lane and increases the timing margin, so a link that is marginal at the intended rate may become clean at a lower one. That result points to channel loss, equalization, connector quality or a timing assumption rather than to a dead lane or a wrong command.

If errors persist at every rate, the problem is more likely to be structural: a swapped pair, a missing clock, a wrong lane count, an initialization error or a power issue. The sweep is still useful because it rules out a pure margin explanation and narrows the next test.

Change one variable at a time. Keep the lane count, cable, temperature and pattern constant while changing the rate. Then repeat with a different lane count, because a link that works with two lanes but not four may have a fault on one pair rather than a general bandwidth shortage. Record each combination and the resulting counter values.

Which routing and connector changes deserve an A/B test?

Change one physical variable per A/B test.

Cable, connector, FPC routing and reference clock affect the eye differently, so test them one at a time against a known-good baseline.

A/B testing is how a physical cause is confirmed. Swap the cable for a known-good one and repeat the same pattern and rate. If the errors follow the cable, the cable is the finding. Swap the panel and repeat. If the errors follow the panel, the panel or its flex is the finding. Only one variable should change per test, otherwise the result cannot be attributed.

Connector mating deserves its own test. A connector that is not fully seated, has a bent contact or has worn plating can produce intermittent errors that disappear when the cable is moved. Mate and unmate the connector a defined number of times and repeat the measurement. A change in the error rate after mating cycles is evidence of contact wear.

Reference clock and spread-spectrum settings are electrical variables, not physical ones, but they belong in the same A/B discipline. Change one setting, repeat the pattern and record the counters. A result that depends on a setting is a configuration finding, not a random failure.

How can rail noise correlate with packet errors?

Correlate error bursts with rail and backlight events.

Capture the error counter, panel rail and backlight PWM on one time base; a burst that follows a rail dip or dimming edge points to power coupling.

Packet errors are often bursty. A single event can produce a cluster of CRC failures, and the cluster may align with a power event: a backlight dimming edge, a charger connection, a motor start or a rail transient. Capturing the error interrupt or a counter increment together with the rail and the backlight control signal makes that relationship visible.

Use a multi-channel capture with the error event as a marker. Include the panel rail, the interface rail and the backlight PWM or enable. If the burst follows a rail dip, the cause is likely power coupling or an insufficient decoupling network. If it follows a dimming edge, the cause may be conducted or radiated interference from the backlight driver. If it is uncorrelated with both, the data path or the connector is the better suspect.

A load switch such as the TPS22918 documents controlled rise and discharge behaviour for a rail; the panel sequence and the decoupling still belong to the module design, so the capture should include the actual rail, not only the switch setting.

What happens if the panel cannot report error status?

Without panel counters, use host counters and frames.

The host controller usually counts ECC and CRC errors even when the panel cannot; pair those counters with captured frames and TE timing to locate the failure.

Many panels do not expose a readable error register. In that case the host controller is the primary observer. Its ECC and CRC counters, its lane-status registers and its interrupt flags describe what the receiver saw. The panel’s behaviour, captured optically, describes what reached the display. Comparing the two narrows the fault.

If the host counts errors but the image looks correct, the errors may be corrected or discarded without visible effect. If the image shows corruption but the host counts nothing, the fault may be after the receiver, in the panel’s internal path or in the display timing. That distinction prevents replacing a healthy panel for a host-side problem.

Use a test pattern with a known structure, such as a moving bar or a fine checkerboard, so a corrupted region is visible and locatable. Capture the frame and the counter values at the same time. The ST AN4860 DSI host application note documents host-side error and packet behaviour for specific STM32 families; the exact counters depend on the controller.

Which stress patterns reveal intermittent corruption?

Use long soaks, full-screen patterns and physical stress.

Intermittent corruption often appears under sustained traffic, temperature change, cable flex or supply ripple, so combine a long soak with a moving full-screen image.

A static image may leave the link idle for long periods. A moving full-screen pattern keeps the link busy and changes the data pattern continuously, which is more likely to expose a marginal lane. Add a slow colour sweep, a scrolling bar and a high-contrast checkerboard, and run them long enough for a rare event to occur.

Combine the traffic with the physical variables: temperature cycling, supply variation, cable flex and connector mating. The failure may require two conditions at once, such as a warm panel and a full-screen pattern. A test matrix that varies one condition at a time can miss it.

Record the pattern, the duration, the temperature and the counter values. A stress test that produces no errors but does not record its conditions cannot be compared with a later failure.

How should a link-error report separate observation from cause?

Separate what was observed from what is suspected.

List counters, timestamps, traffic pattern, temperature and supply as observations, then state the hypothesis and the test that would confirm it.

A useful report has two layers. The observation layer records the counter values, the sample interval, the pattern, the temperature, the supply voltage, the cable and the board revision. The hypothesis layer states what the evidence suggests and what test would confirm or reject it. Mixing the two turns a measurement into an opinion.

The observation layer should also state what was not measured. If the panel has no error register, say so. If the counter saturated, say so. If the failure was seen only once, say so. Those limits are part of the evidence and prevent a later reader from over-reading the result.

The table below is a template for the report. It is not a set of limits; the limits come from the host controller and the panel specification.

Link-error evidence record

Signal or rail	Power state	Trigger or capture point	Observed behavior	Source of acceptance limit
DSI clock lane	HS	Lane trace	Clock presence and stability	Host and panel limits
DSI data lanes	HS	Lane trace	Eye quality and packet activity	Host and panel limits
ECC counter	Active	Host controller register	Header error count over interval	Host documentation
CRC counter	Active	Host controller register	Payload error count over interval	Host documentation
Panel rail	On	Connector pin	Ripple and transient correlation	Panel drawing
Backlight PWM	On	Driver control signal	Edge correlation with error bursts	Driver datasheet

The SN65DSI83 datasheet is an example of a bridge whose device-specific status and error behaviour must be read from its own document; it is not a generic DSI error model. The DRM KMS documentation covers the pipeline context in which the driver samples and reports these counters.