Get the trace log to check.
Hi Shane, here is the trace log:
trace.txt (15.2 KB)
Here are my updated driver and .dtsi files for your reference:
nv_ovx1f.c (14.4 KB)
tegra234-camera-rvs215.dtsi (9.6 KB)
ovx1f_mode_tbls.h (1.2 KB)
I also notice that in dmesg, the device name is different when compared with the device tree. It appears as ovx1f 2-0036 during the probe, when it actually should be ovx1f 30-0036 according to my device tree. I am not sure if affects anything, but I did some modifications to the driver code and the mode table by referring to the below forum post:
And strangely, /dev/video0 appears even if I connect nothing to the CSI camera connector on the Orin. And the same green images are seen with gstreamer command.
Could you update the debug firmware to collect the log.
Hi Shane, I’ll try that out now.
But this needs an ubuntu host PC to flash the Orin right? Or can I run that command from within the Orin itself?
And should I update to r35.1 before I do this?
Need PC and install ubuntu 18.04 for install sdkmanager.
1 Like
Hi Shane, I updated to r35.1, updated the debug firmware.
Here are the trace logs and dmesg logs for the same issue:
dmesg.txt (136.4 KB)
trace.txt (503.0 KB)
Looks like NVCSI/VI didn’t receive any validate package form MIPI bus.
Hi Shane, you were right, the cable we were using inverted the odd pin signals and even pin signals when going from the CSI connector on the deserialiser board to our interface board on the Orin.
Now we’ve patched the cable and we’ve probed and checked that there is CSI signal and clock appearing on the interface board on the right pins.
Loading the driver again and running the following gstreamer command again crashes the Orin.
gst-launch-1.0 v4l2src device=/dev/video0 ! “video/x-raw, format=(string)UYVY, width=(int)1100, height=(int)884, framerate=(fraction)30/1” ! xvimagesink -ev
The trace log tell the SOT error(Start Of Transmission)
That could be the ths_settle problem.
Make sure the timing like below.
Hello again Shane,
we checked the CSI timing and the amplitudes of the signal on the 8 pins of the 4 CSI lanes we are using on our interface board and the board carrying the deser.
When the interface board is connected to the Orin, we notice on the pin on the interface board corresponding to pin 13 of the jetson camera (CSI0_D1_P), that there is a voltage drop. Instead of the usual 1.2V, the observed amplitude is 0.9 V.
On disconnecting the adaptor board from the Orin, and measuring the signal only on the matching adaptor board pin, we observe the full 1.2 V on the same pin. The voltage drop for some reason occurs only when connected to the Orin.
On every other pin, the timing and the amplitudes of the CSI signal are all fine with and without the Orin connected. The clock signals also seems fine.
Do you know if there is any configuration parameter in the driver development which could change voltage only for that particular pin? I don’t recall ever configuring pins directly, I would be happy to hear your suggestions.
As I know don’t have this kind of configure.
Have you come across any other cases where there is a single pin having this voltage drop in maybe other jetson devices?
Or which part/function of the device tree or the driver code communicates with the Orin to look for CSI signal on specific pins? Somewhere it must be communicated to the linux kernel, maybe that’s a point where i could start debugging. Do you have some pointer or suggestions here on where I could start looking?
Hi Shane,
we found that the resistance for the pin 13 (CSI0_D1_P) is around 288 ohms and for every other CSI data pins we are using, the resistance is around 365 ohms to ground. The Orin is switched off during these measurements, so its not a software issue.
Only this pin is terminated differently, has a different resistance and a different voltage. It looks like a physical defect on the camera connector pin 13. Do you know if we can do anything to remedy this?
Do you have extra Orin to confirm if it’s special case.
Thanks
Currently we don’t have a 2nd Orin. Maybe we are allowed to order a 2nd one in the near future.
By the way: Hi, I’m Martin and at least for the moment taking over the topic after Bala finished his Thesis and left the company.
Looks like it’s specific device issue need RMA if confirm without problem on another Orin.
Thanks
How would the RMA work, do you provide some shipping address and we send it in?
Currently we also have some activities to get a new adapter PCB to use a different set of CSI2 lines. I need to check what the status is and if they want to try to continue with the other CSI2 line set.
Currently we are trying to get the RMA process on track: RMA chat sent me here - CSI_data1_p seems to be damaged - different idle voltage, resistance and diode voltage - #4 by Martin_W
In parallel I’m trying to get a 2nd Orin ordered.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.