Resurface of nvccp_set_cam_unit_pwr_on failed status 1001 error

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

Target Operating System
Linux
QNX
other

Hardware Platform
NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)
other

SDK Manager Version
1.9.1.10844
other

Host Machine Version
native Ubuntu 18.04
other

Dear Nvidia Support,

The same error described in Camera initiation returns error: nvccp_set_cam_unit_pwr_on failed status 1001 has resurfaced again on the 13th May 2023. The past three days, we tried repeating all different combinations of previous solutions. Namely:

  • Reflashing both Tegra A dan Tegra B
  • Reflashing Aurix
  • 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?

DEVBLK_WORKER_0: /dvs/git/dirty/git-master_linux/camera/fusa/sipl/src/core/utils/CNvMThread.cpp: 146: m_Func: Running thread:DEVBLK_WORKER_0
DEVBLK_WORKER_0: /dvs/git/dirty/git-master_linux/camera/fusa/sipl/src/core/utils/CNvMThread.cpp: 149: m_Func: Calling ThreadFunc for thread:DEVBLK_WORKER_0
Module_id 30 Severity 2 : src/devblk/fusa/cameramodule/common/utils/pwr_utils.cpp 493
Module_id 30 Severity 2 : nvccp_set_cam_unit_pwr_on failed with status 1001
Module_id 30 Severity 2 : src/devblk/nonfusa/cameramodule/MAX96712cameramodule/CNvMMAX96712CameraModule.cpp 790
Module_id 30 Severity 2 : MAX96712: CNvMMAX96712CameraModule::DoSetPower failed with SIPL error 127
Module_id 30 Severity 2 : src/devblk/common/ddi/ModuleIF/CNvMCameraModule.cpp 70
Module_id 30 Severity 2 : CNvMCameraModule::SetPower failed with SIPL error 127
Module_id 30 Severity 2 : src/devblk/common/core/CNvMDeviceBlock.cpp 678
Module_id 30 Severity 2 : CameraModule SetPower failed with SIPL error 127

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.

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.

Have you tried the other Xavier devkit on hand?

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.

According to our record, you also have a DRIVE AGX Xavier devkit. Could you double-check it on your side?

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.

Information from DRIVE Hyperion 7.1 | NVIDIA Developer. FYI.

I’m checking with our team to see if more things to check.

Information from DRIVE Hyperion 7.1 | NVIDIA Developer. FYI.

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.

Thank you. We await further assistance.

‘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?

Dear @aulia.widyaputra1,
Could you provide any update on Vick’s ask?

Sorry. Was heavily occupied the past few weeks.

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?

Is it looking like Error trying to connect monitor - #8 by jber4282? I see it on my Tegra as well, but I don’t see any issue with using camera.

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.

Dear @aulia.widyaputra1,
Do you still have this issue?

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.