TI AUTOMOTIVE · interfaces
FPD-Link camera diagnostics: from LOCK to per-stream isolation and recovery
Use a DS90UB953-Q1 → DS90UB960-Q1 example to separate power, clock, PoC, harness, serial-link, CSI and SoC VC/DMA faults with evidence-first snapshots, staged tests and bounded recovery.
Sources reviewed 2026-11-07 · NuAxi technical editorial · source facts and engineering interpretation distinguished
Key answer
LOCK establishes receiver lock, not correct sensor frames or completed SoC DMA. First preserve a port-tagged, timestamped snapshot that accounts for clear-on-read effects, then isolate power/clock/PoC, FPD-Link, sensor CSI, deserializer forwarding/CSI, and SoC VC/DMA in turn. Deserializer, serializer and sensor patterns exercise different paths and bypass others. Prefer isolating the failing stream during recovery, but shared CSI, synchronization, power and driver resources can prevent uninterrupted operation of healthy cameras; measure rather than promise it.
1. Fix fault boundaries, device revisions and evidence sources
The main example uses four DS90UB953-Q1 serializers with a DS90UB960-Q1. Give the sensor CSI input, each serializer, PoC/harness, 960 RX port, CSI output and SoC capture queue separate identities. Record full part numbers, board revisions, connector-to-RX mapping, input VC/data type to output VC mapping, I2C aliases, clock mode and power/reset groups. If 'camera 2' means different things at the connector, register page and DMA queue, error counts cannot be attributed reliably.
Keep source facts separate from engineering proposals. The full 960 SNLS589D and 953 SNLS552E datasheets define field semantics and access side effects. SNLA267A supplies segmentation, BIST and pattern-test methods for a 953/954 system; SNLT007 covers power, clocks, patterns and SoC configuration for a 936 black screen. Learn the diagnostic order from these guides, not their old scripts, 954 paging details or 936 electrical values for a 960. DMA investigation, retry budgets and release gates here are engineering test plans, not TI implementation promises for a particular SoC.
Related devices are limited to the existing DS90UB935/962/913A/936/953/954/960 catalog entries. Both 935 and 953 have CSI inputs, but their limits, diagnostic registers and clearing behavior are not thereby identical. The 913A has parallel input: investigate PCLK, width and LV/FV rather than importing 953 CSI receiver diagnostics. The 962 single CSI output and 936/954 replication modes are not the 960's independent dual outputs. This guide makes no 953 → 936 compatibility determination; migration requires both current datasheets and the specific mode. The separate bandwidth guide handles line-service and buffering budgets; this guide uses error evidence to locate faults.
2. LOCK, PASS, CRC/ECC and frame delivery are different evidence tiers
Source fact: the 960 PORT_PASS indication depends on PORT_PASS_CTL. With PASS_THRESHOLD set to zero, PASS can assert after receiver lock without first requiring complete valid frames. Nonzero thresholds, line-size/count checks and parity handling change its qualification. Log the PASS configuration alongside its state; a lit indicator does not mean 'video is good,' and changing a threshold is not a repair.
Always qualify CRC by detector and direction. The 953 back-channel CRC, 960 forward-control-channel BCC_CRC_ERROR, and CSI long-packet payload CRC/checksum are different observations. CSI ECC protects the header: the 953 datasheet distinguishes correctable single-bit header errors, uncorrectable double-bit header errors and uncorrectable payload checksum errors. A corrected event is still an event, not evidence of unlimited margin. Zero errors requires an enabled detector, actual traffic, a defined observation interval and retained history.
Scroll wide tables horizontally; column headers remain visible within the table.
| Observation | What it supports | What it cannot prove / next check |
|---|---|---|
| Local/remote I2C response | A transaction responded on the selected control path; verify the returned identity | Not proof that the sensor is streaming; aliases or auto-ack settings can mislead |
| 960 per-RX LOCK and lock-change history | Current input lock and recorded lock transitions | Not CSI, image-content or DMA proof; one LOCK=1 sample can miss earlier loss |
| 960 PORT_PASS with its configuration | The port met its configured qualification conditions | The default threshold can follow lock; consistently wrong dimensions can still look stable |
| FPD parity, control-channel CRC and encoding errors | The named detector saw an error on its protected transport path | One flag does not distinguish cable, power, clock or configuration causes, or cover optical content |
| 953 CSI input and 960 RX-side CSI status | Header ECC, payload-checksum or length errors at the respective observation point | 960 CSI_RX_STS is not SoC receiver telemetry; correlated events are not independent bad frames |
| SoC per-VC frame boundaries, DMA completion and fresh application frames | Platform logs establish delivery, dimensions and timing; then inspect known image content | DMA can complete for the wrong VC, stale buffer or format; one displayed image is not sustained valid capture |
3. Preserve evidence first: reading registers can change it
Engineering plan: use one diagnostic collector to own paging and destructive reads; do not let the application, GUI and interrupt handler independently consume status without logging it. At a trigger, preserve monotonic host time, reason, configuration version, RX/TX port and VC, last successful frame time, SoC errors and queue state. Define the read order from the datasheet, persist the first raw bytes with their interpretation, and only then explicitly clear, reset or retry. 'Snapshot first' does not mean a clear-on-read field can be read twice non-destructively.
The 960 RX_READ_PORT selector and individual RX_WRITE_PORT enables are different: reads select one port, while writes can target several. Serialize select/access/restore transactions, verify returned port identity and avoid unintended broadcasts. Sequential I2C reads are not an atomic four-camera snapshot. Timestamp individual reads, record acquisition start/end and inaccessible intervals, and use healthy streams as contemporaneous controls rather than treating all values as simultaneous.
Scroll wide tables horizontally; column headers remain visible within the table.
| Field and device | Verified access semantics | Collection consequence |
|---|---|---|
| 960 SNLS589D: LOCK_STS_CHG, BCC_CRC_ERROR | These history flags in RX_PORT_STS1 clear on read; LOCK_STS is current state | Keep the first read; a zero on the second does not disprove the transient |
| 960: RX_PAR_ERR_HI / RX_PAR_ERR_LO | Reading LO clears both counter bytes and the parity flag; lock loss also clears parity count/flag by default | Use the documented collection sequence and mark clearing boundaries; zero after loss of lock is not a clean history |
| 960: PARITY_ERROR | Qualified by PAR_ERR_THOLD, not a one-flag-per-error record | Save threshold and count; a clear flag cannot exclude a small error count |
| 960: CSI_RX_STS / CSI_ERR_COUNTER | CSI error flags clear on read; the counter records errored CSI packets since its last read | Keep error classes and packet counts separately, not as pixel-bit errors or failed-frame counts |
| 953 SNLS552E: CSI_ERR_CNT | RC field counting received CSI packets with errors since the previous read | Accumulate interval samples rather than subtracting two cleared values; do not transfer this behavior to other devices |
| 960: LINE_COUNT and LINE_LEN high/low bytes | Reading high latches low for consistency; relevant change-interrupt enables can freeze values until read | Read each pair as specified and record interrupt configuration; one matching size is not continuous-traffic proof |
- Classify fields as read-only, read-clear, explicit-clear, reset-cleared or cross-byte latched; do not invent clearing recipes for unverified fields.
- The 960 datasheet conditions exact parity-count reads on temporarily disabling parity checking. That changes monitoring coverage and is not passive polling. Use the documented method only in an approved test window, restore it and record the coverage gap.
- Log interval length, actual frame/packet exposure, counter width and clear/reset events; do not assume wraparound or saturation without verifying it.
- Order interrupt summaries and associated status by their clearing dependencies; mark failed remote reads unavailable, not zero, and avoid repeated full-device resets after bus timeouts.
4. No LOCK or intermittent loss: separate power, clock, PoC and harness
Source facts: TI's 936 troubleshooting guide begins with power/reset sequencing and reference clocks; the 953/954 design guide treats mode, back channel, PoC and cable loss separately. Compare local deserializer access, remote serializer access, sensor identity readback, reference-clock status and lock-transition timing. A remote-only failure prioritizes that branch; simultaneous failures raise the priority of shared power, reference clock, reset and host control. This is a triage order, not causation inferred from correlation alone.
Separate clock roles: the 960 REFCLK, 953 synchronous/asynchronous reference source, sensor CLKOUT and actual sensor CSI clock are not interchangeable observations. The serial link can be locked while the sensor remains in reset, lacks its master clock or waits for a trigger. A back-channel mode change can affect both control access and recovered clocks; do not blindly try frequencies in a running system. Preserve actual mode/clock configuration and compare it with a known-good unit of the same revision.
PoC is both a power network and part of the high-speed channel. SNLA267A calls out return loss after adding PoC and inductor current capability under the actual load. A link that fails when the sensor begins exposure/streaming can therefore involve power margin, PoC/harness signal integrity or another simultaneous change, not necessarily CSI configuration. Correlate lock-loss time with load state, protection events and temperature using existing telemetry, approved monitoring points and qualified laboratory measurements.
Start safely with configuration and logs, then inspect connectors, shielding and assembly only after power is removed, stored energy discharged and the board procedure permits it. Follow with a known-good harness/camera cross-test changing one variable at a time. Keep port configuration and mode fixed and observe whether the fault follows the module, harness or port. A cable change can also change the PoC power path, so retain that confounder. Do not short live circuits, casually hot-plug PoC, defeat protection or parallel another supply onto an unknown node. Qualified personnel should perform power isolation or margin tests under an approved bench plan.
5. Use staged patterns and BIST to narrow the path, not certify the system
Source method: SNLA267A section 5.3 starts with a deserializer pattern, then a serializer pattern, then sensor data, avoiding simultaneous introduction of every fault segment. SNLT007 likewise uses a deserializer pattern to check the SoC. The 960 datasheet section 7.5.12 confirms a pattern generator for each CSI transmitter; 953 section 6.6 confirms its internal pattern capability. Save the original configuration and identify affected outputs/cameras first. Pattern generation, BIST and forwarding changes alter traffic; they are not transparent online probes.
Engineering plan: begin with a low-risk single-stream test on an isolated bench or in a maintenance window. At each stage, match receiver VC, data type, dimensions, lanes and clock conditions while recording raw buffers and frame sequence. A small low-rate pattern proves only that test point, not the actual RAW mode or concurrent cameras. Establish the basic path, then restore the target load and repeat the same observation window. Do not change clock, forwarding and sensor parameters together without records merely to obtain an image.
Scroll wide tables horizontally; column headers remain visible within the table.
| Controlled test | Main coverage | Excluded coverage and next step |
|---|---|---|
| 960 internal pattern → SoC raw capture | That CSI output, board connection and current receive/DMA configuration | Bypasses sensor, 953 and FPD-Link; on failure investigate output and SoC before replacing the camera cable |
| 953 internal pattern → 960 → SoC | Adds serializer transmission, serial link and that RX forwarding path to an established downstream baseline | Bypasses sensor CSI input and real imagery; changed traffic prevents a direct attribution to the added segment |
| Sensor-generated pattern → full capture path | When supported and correctly enabled, adds sensor CSI output and the 953 CSI receiver | Usually does not validate optics/pixel array, real exposure or the full ISP path; restore real scenes afterward |
| FPD-Link BIST for the specified devices/mode | Forward/back-channel serial transport exercised by the self-test source and checker | Does not validate sensor, SoC CSI or DMA; establish test activation, duration and traffic before interpreting zero errors |
6. Stable LOCK but no frames: absent sensor traffic, CSI errors or wrong format
Verify sensor state, not just I2C ACK: identity readback, reset/PWDN, mode-table load, stream-on readback, external-trigger requirements and master-clock source must agree. Under the engineering hypothesis 'the sensor sends no packets,' zero 953 errors is entirely plausible because no packets were checked. Cross-check verified sensor frame counters, 953 input header/word-count observations and downstream frame events. A retained header value alone does not establish ongoing traffic.
Source fact: the 953 provides length, payload-checksum and single/double-bit ECC classes in CSI_ERR_STATUS, plus data-lane SoT, SoT Sync and HS-request control errors and clock-lane status. Repeated input errors with quiet contemporaneous FPD parity/BCC observations prioritize sensor-to-953 lane count, rate, polarity, clock mode, routing and timing. This remains a priority, not proof: power disturbances can affect several interfaces, and serial-side clearing or lock loss can hide history. Increasing CSI rate or relaxing error thresholds is not input isolation.
Inspect actual packets rather than configuration intent: the 953 reports VC/data identifier and header Word Count, with header-selection controls for a chosen VC and received versus corrected header. An interleaved image/embedded-data stream can yield the wrong packet class if sampling is selected incorrectly. Interpret payload bytes, image lines and metadata separately before checking 960 VC remapping. Word Count is not pixel count, and legitimately different metadata lengths are not automatically corruption. A 913A path lacks these 953 CSI-input observations and needs its own parallel-timing and RAW-mode checks.
7. After data reaches the 960: follow the output, VC filtering and DMA ownership
Separate the 960 RX-side CSI_RX_STS, per-RX line/frame observations and BUFFER_ERROR from TX-port status. RX CSI errors describe received camera packets, not feedback from the SoC D-PHY. BUFFER_ERROR indicates packet-buffer overflow, not cable damage by itself. If single streams are stable but aggregation overflows, check actual forwarding enables, output mapping, synchronization requirements and the line-service budget using the bandwidth guide rather than diagnosing from average Gbps.
Source fact: the 960 CSI_PASS_MODE can require any one valid input or all enabled inputs, so a healthy camera can keep TX_PORT_PASS asserted. During synchronized forwarding, TX_PORT_PASS indicates data available for delivery, but unsynchronized inputs can still prevent transmission. Interpret TX_PORT_SYNC too; zero is normal when synchronization is disabled. The datasheet also states that synchronization failure stops forwarding and leads to an attempt at a subsequent frame start. Thus 'one camera fails, all images stop' can arise from forwarding dependencies rather than four simultaneous cable faults.
Engineering plan: count SoC D-PHY/CSI errors, per-VC/data-type packets and frame boundaries, received dimensions, DMA completion, overflow and application dequeue separately. Correct-VC frame events without DMA completion prioritize queued buffers, descriptors/interrupts, stride, unpacking and memory resources. Completed DMA with stale application images prioritizes buffer ownership, cache coherency, queue selection and consumers. Mark missing platform counters as observability gaps; do not invent universal registers or assume automatic driver recovery.
The 960 error-handling logic can truncate a frame without sending Frame End and resume with a new Start of Frame. Test the target SoC's response: whether the affected queue releases the partial frame, the next frame realigns, and other VCs on the same output are affected. Matching LINE_COUNT/LINE_LEN establishes expected formatting at that observation point, not actual receiver completion or freshness. Use SNLT007's dimension checks as localization evidence, not an unconditional end-to-end correctness proof.
8. Per-stream recovery example: isolate, retry within bounds, track healthy cameras
Engineering example, not a measured guarantee: four 953 → 960 paths map RX0/1/2/3 to VC0/1/2/3 using validated best-effort forwarding. RX2 capture times out while the other cameras still deliver fresh frames. Capture RX2, one healthy control and SoC queue state, and mark RX2's incomplete frame unusable. Continuous RX2 LOCK with rising CSI input errors directs investigation toward the sensor/input path; lock loss aligned with branch-power faults directs it toward power/link; RX/TX traffic without VC2 DMA completion prioritizes host capture. Do not convert every timeout into a deserializer reset.
Start isolation at the smallest controllable unit: where the datasheet and driver allow it, stop only the failing RX's forwarding, retire the corresponding VC's partial frame and preserve healthy RX mappings, reference clock and frame sync. Per-input forwarding control is a 960 fact; lossless per-VC stop/restart on the actual SoC is a platform question. If the shared CSI receiver requires whole-port reset, a synchronized group depends on the missing stream, or cameras share power/reset, declare the larger interruption domain and use a validated degraded/maintenance procedure. Do not promise zero frame loss for healthy cameras.
Choose the recovery ladder from evidence: repair/rebuild that stream's host queue or verified configuration first, then consider controlled sensor stop/reinitialization, and only later a local module reset or branch power cycle. Each step needs exact device/board support, preserved pre-action configuration and a failure condition; power cycling must respect sequencing and protection cooling requirements. Whole-device reset, shared-reference changes and common-power operations are escalations to a larger fault domain, not hidden parts of a routine single-stream retry.
Define bounded retries before implementation: K maximum attempts, W rolling window, T per-step timeout and M consecutive valid frames for release. Select them from system requirements and bench measurements, not a universal camera delay. Exhausting K/W, or power/thermal protection prohibiting recovery, keeps that stream unavailable and reports it instead of creating an endless reset loop. Log reason class, attempt index, action scope, duration, clear/reset boundaries, discarded frames, healthy-stream inter-frame gaps and terminal failure. Repeated lock flapping should produce an incident with cumulative statistics, not a fresh zero history after each reset.
Release requires progression from lock to fresh-frame delivery: in a new observation window verify input errors, forwarding state, VC/format and frame completion, then establish freshness using monotonic timestamps, frame sequence or a controlled changing scene. Image hashes alone are insufficient because a static scene can legitimately repeat. Mark discontinuity on the recovered stream and rejoin synchronization groups under system requirements. Preserve measured healthy-stream cadence, VC identity and any additional frame loss as part of recovery acceptance.
9. Acceptance checklist: localize, preserve evidence and bound recovery
These are engineering verification gates, not functional-safety certification, diagnostic-coverage claims or SoC recovery guarantees. Keep separate normal, fault-injection and recovery windows. Use only approved software controls, test modes or safe fixtures for injection, not improvised shorts or live cable removal. After single-stream success, add streams progressively and repeat under the target concurrency and environmental envelope.
- Archive full device/revision, physical RX, VC/data type, CSI output and DMA mapping, plus shared power, reset, clock and frame-sync dependencies.
- Establish actual sensor traffic with configuration readback and packet/frame observations, not I2C ACK or a LOCK indicator.
- Assign one owner for destructive reads; retain first raw reads, timestamps, page identity, thresholds, detector enables and unobservable intervals.
- Record parity, direction-specific CRC, CSI single/double-bit ECC, length and overflow separately; do not double-count correlated observations as failed frames.
- Label each pattern/BIST stage with bypassed paths, mode and duration; revalidate real input at target load afterward.
- Check 960 PASS threshold, TX any/all-port semantics and synchronization mode; ensure healthy streams cannot mask a failed stream.
- Cover sensor stop with LOCK retained, controlled single-link loss, wrong VC/format and host buffer starvation; verify distinct diagnoses and actions.
- Validate queue cleanup/resynchronization after truncated frames, missing Frame End and a new Start of Frame; ensure stale buffers are not labeled fresh.
- Publish K/W/T/M, terminal-unavailable state and escalation scope; compare healthy-camera frame counts, maximum inter-frame gap and synchronization skew before/after the fault.
Frequently asked questions
Why is there no video when DS90UB960 LOCK and PASS are both one?
PORT_PASS is configuration-dependent; PASS_THRESHOLD=0 allows it after lock. The sensor may still be idle, forwarding disabled, or the SoC filtering the wrong VC/data type. Preserve destructive-read history first, then establish sensor packets, frames on the intended output and DMA completion separately.
Why does the first read show errors and the second show zeros? Is the second a clean result?
Not directly. The 960 lock-change and some control-channel/CSI flags clear on read; reading RX_PAR_ERR_LO clears parity counts; 953 CSI_ERR_CNT also starts a new interval at each read. Keep the first sample, detector settings and time window, including the 960's default parity clearing on lock loss. Zero may mean consumed or reset history, not that no error occurred.
The 953 reports single-bit ECC but the 960 has no serial parity errors. Should I replace the coax first?
Prioritize the sensor-to-953 CSI contract and connection, especially lanes, timing, polarity, clock mode and actual headers. Single-bit ECC is a header-correction event, not payload CRC or a synonym for coax errors. Correlate power and serial history over the same interval; one cleared sample cannot absolve the coax entirely.
Why can real camera capture fail after zero-error BIST?
BIST covers the serial path between its source and checker, not sensor CSI input, SoC VC/format filtering or DMA. Establish that BIST actually ran for the recorded interval. Then test deserializer, serializer and sensor patterns and real scenes, tracking differences in format and load.
Why do healthy cameras stop updating when one camera stops?
960 synchronized forwarding requires valid synchronized participating inputs and can stop output on failure. CSI receivers, DMA drivers, frame sync and power can also be shared. Check forwarding mode and fault domains before testing isolation of only the failed RX/VC. Independent RX ports do not guarantee independent recovery, and changing forwarding mode requires validation.
Do correct LINE_COUNT/LINE_LEN and DMA completion justify immediate release?
Not alone. Verify the intended port/VC, byte and metadata interpretation, consecutive fresh frames, valid timestamps, complete frame boundaries and application buffer ownership. Recovery can involve truncated frames or repeated Start of Frame. Release only after target-SoC cleanup and resynchronization meet the tested gate.
Can these 953/960 diagnostics and clearing rules be used directly on 935, 936 or 962?
No. Reuse the method—locate observations, preserve first reads, run controlled segmented tests and bound recovery—but verify fields, paging, clocks, error coverage and clearing dependencies for each device. The 913A is also a parallel-input device. This guide provides no 953 → 936 pairing approval, universal register addresses or cross-platform reset script.
Related parts and complete OPNs
Continue reading
NuAxi is independent of TI. This guide organizes official evidence and engineering checks; it is not substitution approval, system certification, procurement assurance or completed design validation. Review the exact OPN, datasheet revision and project requirements.