Hey everyone, hoping someone can point me in the right direction here. I’m running an Arducam ToF Camera on a Jetson Orin Nano and it was working fine until the camera cable got accidentally yanked and disconnected while the system was running. After rebooting the Jetson, the camera seems to initialize — it shows up over I2C, the device node gets created — but I’m getting no frames at all when I try to stream. Just… nothing. I’ve tried rebooting a couple of times already. Same result every time: it looks like the sensor is found but no video data comes through. Anyone seen this before?
This is a pretty common failure pattern, unfortunately. The fact that I2C works (sensor initializes, device node created) but you get zero frames during streaming points very specifically to a problem on the MIPI data lanes — not a complete port failure, since I2C is still functional on the same physical connector.
The accidental cable pull while powered is the smoking gun here. It likely caused physical damage to one of the interfaces. The candidates are:
- The CSI port on the Jetson itself
- The flex cable / adapter cable
- The camera module’s connector
Before jumping to conclusions, I’d recommend a round of cross-testing to isolate exactly which component is damaged:
- Test the camera and cable: Connect your Arducam ToF (with the same flex cable) to another device — a Raspberry Pi or another Jetson — and see if it streams.
- Test the Jetson CSI port: Connect a different known-working camera to the same CSI port on your Orin Nano and check if it streams.
My bet is on the Jetson-side CSI connector or the cable, but cross-testing will tell us for sure. Let us know what you find.
Alright, did the cross-testing. Here’s what I found:
-
Same Arducam ToF camera with the same flex cable connected to a Raspberry Pi — streaming works perfectly. So the camera module and the flex cable are both fine.
-
Back on the Jetson Orin Nano, the sensor still registers and the device node appears (so I2C is good), but during streaming there’s just no image data coming in.
-
And here’s the kicker: I took a close look at the CSI connector on the Jetson board and the little locking tab is physically broken. Like, snapped off. I tried pressing down on the connector to apply even pressure and hold it in place while streaming, but that didn’t help either. Still no frames.
So it seems like the CSI connector on the Jetson side took the damage. Question — is there any way to remap the Arducam ToF from the damaged CSI port (CSI1) over to the other CSI port (CSI0) on the Orin Nano? Maybe through device tree changes or driver config? I’d rather not ditch the whole board if there’s a software workaround.
Good cross-testing — that gives us a clear picture. The fact that the camera and cable work flawlessly on the Pi, combined with the broken locking tab and no data on the Jetson side, confirms the diagnosis: the primary CSI port on your Orin Nano has partial hardware damage. The I2C traces are still intact (hence sensor detection and device node creation), but one or more of the MIPI data lanes are broken — which explains the complete absence of frame data.
As for remapping to CSI0 — unfortunately, this is not supported with the Arducam ToF driver package. The driver and the device tree blob (DTB) are compiled specifically for the primary CSI interface alignment. The sensor node is hardcoded to that interface. There’s no overlay file or config switch available to simply reassign the camera to the secondary CSI port.
Getting it to work on CSI0 would require manually modifying the kernel device tree source, reconfiguring the sensor node for the alternate CSI interface, and recompiling the DTB — and even then, the driver itself may have assumptions baked in about which CSI instance it binds to. It’s not a simple configuration change, and there’s no pre-built package that enables this.
So unfortunately there isn’t a software-side workaround for the damaged connector. The board’s primary CSI port has a hardware failure on the MIPI data lanes, and the driver doesn’t support port remapping.
That makes sense, even if it’s not what I was hoping to hear. Thanks for the thorough explanation — at least now I know exactly what I’m dealing with and I’m not chasing driver bugs or software gremlins. Appreciate the help!