Please provide the following info (check/uncheck the boxes after creating this topic): Software Version
DRIVE OS Linux 5.2.6
DRIVE OS Linux 5.2.6 and DriveWorks 4.0
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other
Testing on Drive Software 10 Xavier, Drive Software 10 Pegasus XT, DriveOS 5.2.6 Xavier, and DriveOS 5.2.6 Pegasus XT
Testing on all ports and links on both Tegra A and Tegra B
Testing using different SF3224 and SF3225 cameras, coax cables, and fakra cables
Are there any other suggestions from Nvidia apart from the above?
Reading the following section of the error log from running nvsipl, the error seems to be from the MAX96712 deserializer. Given that we’ve tried all manner of software reinstallation, we hypothesize that there may be something wrong with the MAX96172 hardware module. How should we resolve this?
Below is a list of relevant information and logs from the last configuration of testing. Please refrain from asking us to repeat different configurations. The error messages and logs are practically the same. We’re also strapped for time and are trying to find an alternative approach using other non-camera sensors for our immediate plans. We also don’t have another Xavier/Orin board on hand. As for camera usage, we make sure to poweroff using Aurix and turn the power adapter off before inserting and removing cameras. We do however, commonly transport the AGX between the vehicle testbed and lab.
DriveOS 5.2.6 Pegasus XT
4x SF3224 cameras attached on csi-a.
Aurix version
No dropped connection between Tegra and Aurix ping_aurix.txt (1.0 KB)
Just to confirm, are you using the 3324 camera module listed on https://developer.nvidia.com/drive/ecoystem-xavier#camera instead of the 3224 module? If so, have you attempted to connect only one camera module, and is it possible that the issue with a specific camera module only? Additionally, have you tried any other supported camera modules besides the one from Sekonix?
Just to confirm, are you using the 3324 camera module listed on DRIVE AGX Xavier Sensors & Accessories | NVIDIA Developer instead of the 3224 module?
My bad. Yes, we’re using the Sekonix 3324 and 3325 modules supported by Nvidia.
have you attempted to connect only one camera module
Yes. We’ve tried connecting one camera modules on each csi port. Same error.
Additionally, have you tried any other supported camera modules besides the one from Sekonix?
No. We don’t have any other camera modules apart from the 3324 and 3325 by Sekonix. Although we’ve tried multiple cameras of the same model. Still same error.
We don’t have another Xavier devkit. We only have a single Pegasus XT devkit. We simply tried flashing the Tegras using both Xavier and Pegasus XT options in the sdkmanager in the hopes that it might solve the issue.
We have one Jetson Xavier, one Jetson Orin, and one DRIVE AGX Xavier/Pegasus XT devkit.
Just to clarify, we’re not too sure what the difference between Xavier, Pegasus, and Hyperion is. It’s quite confusing from the webpage. Our AGX devkit is the model that contains discrete GPUs in addition to the integrated GPUs. Our assumption is that AGX Xavier is the model without the discrete GPUs, Pegasus XT is the model with the discrete GPUs, and Hyperion is an AGX devkit with additional sensors that can immediately be used on a car.
As an additional note, we did try running both nvsipl and sample_camera with the Xavier variant of Drive Software 10 and DriveOS 5.2.6. Same result.
Yes. That was our reference as well. Additionally, we checked our email history. The board that we purchased is the NVIDIA DRIVE AGX Reference Board (E3550) with "optional dGPU SXM2". Our email history state that it’s the Pegasus model as well. Regardless, we only have one devkit. So asking to check on another devkit is not possible.
I’m checking with our team to see if more things to check.
‘nvccp_set_cam_unit_pwr_on failed with status 1001’ means network timeout error. I want to confirm that there is no other application running with high network bandwidth when encountering the issue, correct?
No other application was running. The nvsipl sample program and camera sample program was often the first program ran after booting.
The network timeout error is an interesting insight though. A question. When identifying the camera type, does the program infer the camera type from the config or does it query the hardware directly?
Some additional information that might be related. Whenever we reboot the Tegra and connect to the CLI using Putty, at tty login, a message regarding unable to update the Marvell firmware always prints. We’ll try to get a screenshot of the message soon. Our assumption is that some internal switch in the AGX cannot automatically update its firmware. This message also pops up even when the cameras worked. So we’ve just ignored it so far. Reflashing the Tegra or Aurix using stated methods doesn’t solve this error. Is this possibly related to the issue? If so, how do we solve this?
Yes. That’s the error that occurs. We also don’t think that it’s related to cameras not working. Just wanted to give additional information just in case it might be related.
Yes, this issue still persist. We are still unable to use our Sekonix cameras connected to the csi ports. Our current workaround is to use usb cameras. However, this is not ideal. Further suggestions that are different from the above actions that we have already tried are incredibly welcome.
