Hi NVIDIA team,
I am bringing up an ST VL53L9CX / STEVAL-VL53L9 one-lane MIPI CSI-2 source on a Jetson Orin Nano Super devkit running JetPack 6.2.3 / L4T R36.5.2.
I have narrowed the failure substantially and would appreciate guidance specifically on the T234 NVCSI CIL clock-lane LP state machine, rather than basic DT / tegracam bring-up.
Hardware / known-good comparison
Jetson:
- Orin Nano Super devkit
- P3767-0005 module + P3768 carrier
- J21 / serial_c
- port-index = 2
- 1 D-PHY data lane
- VC0
- RAW8 / CSI DT 0x2A
Sensor:
- ST STEVAL-VL53L9 / VL53L9CX
- Sensor controlled over I2C with the ST ULD
- Sensor remains in streaming FSM state
- Frame counter advances at approximately 99-100 fps
- Sensor error state remains zero
The exact same VL53 board and ribbon works correctly on Raspberry Pi 5 RP1:
- 1 Gbps: approximately 100 fps, clean capture
- matched 100 Mbps: approximately 100 fps, clean capture
- no RP1 D-PHY / packet / frame errors
The same Jetson J21 receiver also works correctly with a Raspberry Pi Global Shutter IMX296 camera at approximately 1188 Mbps, so J21 itself is known-good.
Jetson configuration path
The live device tree and endpoint graph have been verified from the running system.
The active path is serial_c / port-index 2 / one lane.
RCE SET_CONFIG and STREAM_OPEN both return success.
The sensor continues producing frames, but Jetson captures 0 bytes.
The receiver never reaches:
- SoT
- FS
- FE
- CHANSEL
- STREAM
- HOST1X packet activity
Failure signature
With camrtc log level 2, the dominant error is:
PHY_INTR0, brick 1 / CIL A, raw status 0x00000001
R36.5.2 identifies this as:
DPHY_ERR_CLK_LANE_CTRL
At matched 100 Mbps, this occurs in repeatable bursts. No packet-level progress follows.
At 1 Gbps the same CLK_LANE_CTRL error class occurs, although much less frequently.
With lp_bypass_mode = 0, CLK_LANE_CTRL remains present and CIL_INTR1 additionally reports:
0x00000400
which corresponds to the public T234 symbol:
DPHY_CLK_LANE_ULPM_REQ
I am NOT assuming that this means the VL53 transmitted a standards-valid ULPS request. I would specifically like clarification on what physical / state-machine condition causes T234 to assert this bit.
Controls already eliminated
We have already tested or source-audited the following:
- lane polarity
- one-lane configuration
- 100 Mbps and 1 Gbps operation
- receiver-before-sensor sequencing
- sensor-before-receiver sequencing
- repeated sensor STOP / START
- sensor reset / firmware restart
- lp_bypass_mode = 0 and 1
- discontinuous_clk
- t_clk_settle
- different L4T 36.5.x Linux-side versions
- live DT / endpoint configuration
discontinuous_clk was source-audited in R36.5.2. It is parsed into the sensor signal properties, but I could not find it propagated into csi5_fops / RCE / CIL programming, so changing that property does not appear to change the receiver configuration.
t_clk_settle
I patched the official nvcsi_cil_config::t_clk_settle field through the RCE ABI and verified that the requested value changes the programmed CIL state.
At 100 Mbps:
request 0/default:
CONTROL_0 = 0x2346b2b3
request 27:
CONTROL_0 = 0x0d1ab2b3
request 35:
CONTROL_0 = 0x1122b2b3
request 43:
CONTROL_0 = 0x152ab2b3
request 70:
CONTROL_0 = 0x2346b2b3
request 120:
CONTROL_0 = 0x3c78b2b3
Explicit 70 reproduces the firmware-computed default bit-for-bit.
Values below and above the default changed the number of CLK_LANE_CTRL interrupt bursts, but did not change the failure class.
No tested settle value produced:
- SoT
- FS / FE
- CHANSEL
- STREAM
- HOST1X
- nonzero captured bytes
The default-equivalent value produced the lowest error activity of the tested series.
Inverse-order acquisition test
We also tested whether this was specifically caused by the VL53 LP-to-HS START transition.
Sequence:
- Jetson CSI receiver fully closed
- VL53 started at 100 Mbps
- Sensor confirmed continuously streaming at approximately 100 fps, FSM healthy, ERR 0
- Sensor left completely untouched
- Jetson CSI receiver opened into the already-running stream
- Capture attempted
- Receiver closed again while VL53 continued streaming
- Receiver re-opened again into the same continuously running stream
- Only after both attempts was the VL53 stopped
Both acquisitions reproduced the same pre-SoT CLK_LANE_CTRL failure with 0 bytes.
Interestingly, the second receiver arm generated a burst beginning with data-lane control errors similar to the previous “START burst”, even though the transmitter had made no START / LP transition at all.
This suggests that at least some of that signature is generated by the CIL arming and interpreting the current lane state rather than by a new sensor-side transition.
CAPTURE_PHY_STREAM_DUMPREGS_REQ
I also tested CAPTURE_PHY_STREAM_DUMPREGS_REQ on this RCE firmware.
It was attempted:
- before / after open
- before / after close
- real CSI port and unspecified port
- both bricks
- camrtc log level 3 with string tracing
All attempts returned INVALID_PARAMETER and RCE emitted no register dump.
RCE firmware is unchanged between those tests and the current experiments.
Questions for NVIDIA
- On T234, what exact electrical / LP-state condition causes PHY_INTR0 bit 0, DPHY_ERR_CLK_LANE_CTRL?
The public definition describes a clock-lane LP sequence error, but I would like to understand what specific state transition or illegal state the CIL is detecting.
- What exactly causes CIL_INTR1 bit 10, DPHY_CLK_LANE_ULPM_REQ, on T234?
Does this correspond to detection of LP10, attempted ULPS entry, an aborted LP sequence, remote-reset detection, or another clock-lane condition?
- Does the T234 D-PHY receiver require observing LP11 / Stop State before entering HS reception?
In particular, is opening / arming the CIL while the source is already continuously transmitting HS expected to fail acquisition?
- Are there T234-specific controls for any of the following which are programmed internally by camrtc/RCE but are not exposed through nvcsi_cil_config?
- LP comparator thresholds
- LP input filtering
- deglitch / debounce
- Stop State qualification
- ULPS / ULPM detection
- LP sequence timing
- clock-lane state-machine configuration
-
Is there a supported RCE / NVCSI diagnostic that exposes the current clock-lane LP state or Stop State on T234?
-
Are there known interoperability issues between T234 NVCSI and ST CSI-2 transmitters where the same D-PHY stream is accepted by Raspberry Pi RP1 but T234 reports CLK_LANE_CTRL before SoT?
-
Are there additional T234 clock-lane timing parameters calculated internally by RCE besides t_clk_settle that are not represented in the public nvcsi_cil_config structure?
-
Is there an internal NVIDIA diagnostic or register dump that can distinguish something like:
LP11 → LP01 → LP00 → HS
from a clock lane being interpreted as:
LP11 → LP10 / ULPS-like state
without requiring external electrical measurement?
Related ST / Orin case
I found another ST camera case on the NVIDIA forum with a notably similar architecture: ST VD66GY / VD56G3 evaluation hardware works on Raspberry Pi, the sensor is confirmed streaming, but Orin receives no frames.
That thread is here:
At this point we are preparing a Pi-versus-Orin electrical comparison of CLK_P / CLK_N, but I want to make sure there is no T234-specific CIL requirement, closed-RCE control, or internal diagnostic we are missing before moving to physical probing.
The key question is:
T234 CIL reports PHY_INTR0 bit 0 / CLK_LANE_CTRL before SoT, while the exact transmitter is accepted by RP1. What exact T234 state-machine condition generates this error, and what internal controls or state visibility are available for diagnosing it?
I can provide the complete RTCPU traces, patched csi5_fops.c, live device tree, RCE register snapshots, raw interrupt classification, and full test matrix if useful.
Thanks.