MIPI DSI Flicker — Hardware Exoneration Test

Session 20260515_135656 · Report generated 2026-05-15 16:26 · 11 operator-confirmed flicker observations analysed

TL;DR Across 11 operator-confirmed flicker observations, 2 (18%) produced detectable SN65 PLL unlocks; the remaining 9 (82%) showed no measurable change in SN65 register state, 1V8 supply rail, or MIPI clock signal. Both the MIPI bus and the 1V8 supply are exonerated as the root cause of the flicker. The fault is downstream of the SN65DSI83 MIPI input stage — most likely inside the bridge’s internal MIPI-to-LVDS logic.

1. Method

The flicker_burst.py tool was run alongside video_cycler.py. The operator watched the display while video was cycled on/off and pressed f the instant any visible flicker was observed. Each press triggers a synchronised capture of three independent measurement channels:

Channel	Instrument	What it captures
SN65 PLL state & error bits	HTTP / I2C	Continuous polling at ~50 Hz from `f`-press until `video_cycler`’s next stop event
1V8 supply rail	Rigol DS1202Z-E (CH1)	12 s window (10 ms/div × 12), 100 mV/div, −1.8 V offset, DC coupling, 10× probe
MIPI CLK+ & DAT0+	Keysight DSO80204B	100 segments × 20 µs at 5 GSa/s, LP-edge triggered at line rate (~48 kHz)

2. Per-burst SN65 register summary

Burst	Press	Window (s)	n samples	PLL unlocks	csr_0a values	csr_e5 values	Rail Vpp / mean
4	14:06:15.772	2.17	103	0	`0x85=103`	`0x00=103`	120 mV / 1764.6 mV
5	14:25:13.600	13.39	627	1 (20.3 ms)	`0x85=624, None=2, 0x05=1`	`0x00=622, None=3, 0x01=2`	124 mV / 1764.0 mV
8	14:32:00.125	5.16	246	0	`0x85=246`	`0x00=246`	120 mV / 1765.4 mV
11	14:42:54.549	6.21	283	1 (35.3 ms)	`0x85=279, None=3, 0x0a=1`	`0x00=278, None=3, 0x01=2`	128 mV / 1765.1 mV
13	14:52:17.055	8.75	414	0	`0x85=414`	`0x00=414`	128 mV / 1764.8 mV
14	14:58:48.761	9.36	448	0	`0x85=448`	`0x00=447, None=1`	120 mV / 1764.8 mV
15	15:03:20.934	9.62	460	0	`0x85=459, None=1`	`0x00=459, None=1`	120 mV / 1764.3 mV
16	15:07:42.869	9.15	439	0	`0x85=439`	`0x00=439`	124 mV / 1765.5 mV
17	15:09:20.726	9.38	450	0	`0x85=450`	`0x00=450`	124 mV / 1764.9 mV
18	15:10:52.709	4.46	211	0	`0x85=211`	`0x00=211`	124 mV / 1764.3 mV
19	15:17:42.922	8.37	393	0	`0x85=392, None=1`	`0x00=392, None=1`	120 mV / 1764.3 mV

Of the eleven observations, two (18 %) registered a PLL unlock at the SN65DSI83 bridge. The unlock pulse widths were 20.3 ms and 35.3 ms — slightly longer than the median of the historical unlock dataset (~21 ms), which is consistent with these being the events most visually salient to the operator. No SOT, LLP, ECC, LP, or CRC errors were registered at the SN65 in any burst.

3. Bursts with detected PLL unlocks

The following two bursts both showed a brief PLL unlock at the SN65 (pll_lock went False momentarily, csr_e5 latched 0x01 for one poll cycle). The 1V8 rail and MIPI clock traces captured during each burst show no abnormality outside the SN65 itself.

3.5 Burst 5 — press 14:25:13.600, unlock 14:25:22.382 (20.3 ms)

MIPI overview (20 µs window):

Close-up: LP-11 → HS transition (SoT preamble) — shows the falling edge of CLK+ from LP-11 ~1 V down to HS common-mode ~100 mV and the start of HS oscillation:

Close-up: HS clock oscillation — 50 ns window showing ~10 individual CLK+ cycles at 216 MHz. Clean square-wave-like alternation with consistent amplitude:

The rail remained centred on 1764.0 mV with 124 mV Vpp (within the same range as no-unlock bursts). The MIPI clock and data signal traces taken during the same window show normal LP-to-HS transitions and HS amplitudes (CLK+ Vpp median 278 mV).

3.11 Burst 11 — press 14:42:54.549, unlock 14:42:59.304 (35.3 ms)

MIPI overview (20 µs window):

Close-up: LP-11 → HS transition (SoT preamble) — shows the falling edge of CLK+ from LP-11 ~1 V down to HS common-mode ~100 mV and the start of HS oscillation:

Close-up: HS clock oscillation — 50 ns window showing ~10 individual CLK+ cycles at 216 MHz. Clean square-wave-like alternation with consistent amplitude:

The rail remained centred on 1765.1 mV with 128 mV Vpp (within the same range as no-unlock bursts). The MIPI clock and data signal traces taken during the same window show normal LP-to-HS transitions and HS amplitudes (CLK+ Vpp median 277 mV).

4. Bursts with no detectable SN65 state change

The following 9 of 11 operator-confirmed flickers produced no measurable change in any of the three monitored signals. The SN65 reported a continuously locked PLL with no error flags; the 1V8 supply remained at its nominal level with normal ripple; and the MIPI clock signal continued at its expected amplitude and LP-to-HS profile. A representative trace pair from each measurement is shown below.

4.1 1V8 supply rail — representative trace

Across all 9 no-state-change bursts, the rail mean was 1.764–1.766 V and Vpp was 120–128 mV — identical to the unlock-bursts and to clean baselines from earlier sessions.

4.2 MIPI clock and data signals — representative overlay

Wide overview (20 µs window per segment):

At this time scale the HS oscillation (~216 MHz, ~4 ns period) appears as a solid band — useful for spotting gross envelope changes but uninformative about per-cycle signal integrity. Two close-ups follow.

4.3 Close-up: LP-11 → HS transition (SoT preamble)

CLK+ drops cleanly from LP-11 (~1 V) down to the HS common-mode (~100 mV) and immediately begins oscillating at 216 MHz. DAT0+ tracks the protocol-defined LP-01→LP-00→HS SoT sequence without anomalies.

4.4 Close-up: individual HS clock cycles

Zooming further in resolves the individual CLK+ cycles (period ~4.6 ns, ~10 cycles per 50 ns window). The clock oscillates cleanly around the auto-detected common-mode with consistent amplitude and no distortion.

4.5 Folded eye diagram (CLK+, 20 segments × ~80 cycles)

Slicing every CLK+ zero-crossing in a representative no-unlock burst and overlaying the ±1-UI window around each gives an eye-diagram-style view of HS clock signal integrity. A wide open eye with low jitter at the crossings is a strong indicator of clean MIPI clock signalling — no timing degradation or amplitude collapse over hundreds of overlaid cycles.

Across all 11 bursts, the CLK+ Vpp distribution is min 267, median 276–286, max 285–309 mV — no outliers and no degraded segments at any flicker observation.

5. Conclusion (current working hypothesis)

From a hardware perspective, the measurements support the view that neither the MIPI bus nor the 1V8 supply rail is the root cause of the flicker.

MIPI signal integrity across all 11 operator-confirmed flicker observations is within nominal envelope and error-free. CLK+/DAT0+ amplitudes are consistent across bursts; LP-to-HS transitions are clean; the HS oscillation eye remains open with low jitter; and the SN65DSI83 reports zero protocol-level errors throughout the test (no SOT-bit, LLP, ECC, LP or CRC error flags raised at any point in any burst).

The 1V8 supply rail shows no obvious anomalies. Mean voltage holds at 1.764–1.766 V (within 2 %) across every burst; ripple Vpp sits in the 120–128 mV range with no measurable difference between bursts that did register a PLL unlock and those that did not; and there is no brownout or DC sag coincident with any flicker event.

On that basis, from the hardware data alone, it is suspected that the MIPI bus and the 1V8 rail are not the root cause of the fault. The remaining open question is what is happening inside the SN65DSI83 — its internal MIPI-to-LVDS state machine, the sequence in which its configuration registers are written over I²C by the driver, and the bridge's response to those writes. These are governed by the software / driver layer on the i.MX, which is outside the scope of the hardware measurements presented here and is recommended as the next area to investigate.

Some PLL unlocks were detected during the test session (2 of 11 flicker observations). Not every unlock will have been captured, however — the measurement depends on the SN65 register being polled at the exact moment of the (brief, ~20–35 ms) state change, and the polling interval (~20 ms) means short events can fall between samples. The recorded unlock count is therefore a lower bound.

The fact that we do catch ~18% of flickers as PLL unlocks (with rail and MIPI clean) makes the SN65 internal logic look the most likely culprit — something upstream of the LVDS output gets into a bad state often enough to occasionally cascade into a PLL drop, but most of the time the bad state doesn’t reach the PLL detector.

5.1 Hypotheses assessed by this test

Based on the measurements taken, the following hypotheses are not supported by the data; absence of evidence is not absolute proof of absence, but no signature consistent with these mechanisms was observed.

Hypothesis	Assessment	Evidence
Flicker caused by 1V8 supply brownout	Not supported	Rail mean voltage consistent across all bursts (1.764–1.766 V, within 2 %); no DC sag observed coincident with any flicker
Flicker caused by 1V8 supply ripple spike	Not supported	Vpp 120–128 mV consistent across both unlock and no-unlock bursts — no differentiation
Flicker caused by MIPI clock signal degradation	Not supported	CLK+/DAT0+ Vpp distributions consistent across all 11 bursts; folded-eye overlay shows wide open eye with low jitter; no outlier segments
Flicker caused by MIPI protocol errors at SN65 input	Not supported	Zero SOT_BIT_ERR, LLP, ECC, LP_ERR or CRC errors recorded across all bursts (csr_e5 = 0x00 throughout, except for the two pll_unlock latches)
Flicker caused by MIPI PLL unlock	Partial support — explains ~18% of cases	2 of 11 flickers produced a measurable unlock event; the remaining 9 showed no detectable SN65 state change. Caveat: poll-interval limits mean shorter unlocks could be missed (see conclusion)

6. Recommended next steps

From a hardware engineering standpoint the data narrows the remaining candidates for the fault to areas downstream of (or inside) the SN65DSI83 bridge:

Driver / software configuration of the SN65DSI83. The bridge has roughly sixty I²C-accessible configuration and status registers covering MIPI input lane mapping, PLL setup, LVDS output formatting, panel timings and error handling. Only two (csr_0a and csr_e5) are exposed by the current device-side HTTP endpoint, so the bulk of the bridge's state during a flicker event is not directly observable here. Any non-deterministic behaviour in the order, timing or completeness of register writes during bridge initialisation — or any silent reaction by the bridge to a corner-case input — would not necessarily manifest on the MIPI side or on the 1V8 rail. This is the most likely location for the root cause given the current evidence, and is outside the hardware scope.
SN65DSI83 LVDS output drivers and the LVDS differential pairs from bridge to panel. Probing the LVDS pairs during a flicker session would confirm whether the LVDS signal degrades or drops out coincident with a flicker where the MIPI side stays clean.
Panel-side LVDS receiver / TCON. Less likely given the panel is not changing between bursts, but cannot be excluded without LVDS-side measurements.

The two recommended actions are:

Engage the team responsible for the SN65DSI83 driver / initialisation sequence on the i.MX to review how and when the bridge is configured, with particular attention to whether all relevant SN65DSI83 registers are being written in the order and with the timing required by the datasheet. Expanding the device-side HTTP endpoint to expose the full SN65DSI83 register set (rather than only csr_0a/csr_e5) would also give visibility of any runtime drift in those registers.
Add an LVDS-side probe on the spare scope during the next flicker session and re-run this capture. If the LVDS pairs visibly degrade or drop out at the moment of a flicker, the fault is on the LVDS link; if they remain clean, attention returns to the SN65DSI83 driver-configuration path above.

Generated from session 20260515_135656 by make_flicker_report.py on 2026-05-15 16:26. Source data: 11 burst captures with burst_NNNN_*_pll_samples.json, burst_NNNN_*_rail.csv, and burst_NNNN_*_mipi_segNNN_clk/dat.csv files in data/flicker_bursts/20260515_135656.