Arducam IMX477 stereo HAT registers read 0x00, no video stream on Jetson Xavier NX

Hi all, hoping someone here can help me out. I’ve got a UCTRONICS B0347N stereo camera bundle (the Arducam 12MP synchronized stereo kit, IMX477) that I’m trying to run on a Jetson Xavier NX official dev kit, and I just cannot get any video out of it.

What’s really strange is I’ve now tried three different HAT boards, six different cameras, and two separate Xavier NX dev kits, and every single combination gives me the exact same result. That’s making me think it’s not the hardware. i2cdetect shows the HAT at 0x24 on bus 10 and something at 0x19 (shows UU), so the I2C bus looks alive, but I never get a live feed.

I also tried reading the firmware date registers on the HAT and they all come back empty (0x00). Does anyone have a datasheet for this HAT? I can’t find one that actually describes what the registers do.

Thanks for the detailed report. The fact that you’ve swapped 3 HATs, 6 cameras, and 2 dev kits and still get the identical result really points at firmware/software rather than a hardware fault.

First thing I’d like to confirm is the firmware version. On this HAT the firmware date is exposed over I2C at device 0x24 on bus 10, registers 0x05, 0x06, and 0x07. Can you run these three and paste the output?

i2cget -y 10 0x24 0x05
i2cget -y 10 0x24 0x06
i2cget -y 10 0x24 0x07

If those read back as zeros it usually means the HAT is running older firmware that doesn’t implement the time-setting feature yet, and that would explain a lot.

Sure, here you go. Host is ngps-jetson-2, JetPack 32.6.1, kernel 4.9.253-tegra (uname -r).

ngps@ngps-jetson-2:~$ i2cdetect -r -y 10
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- --
20: -- -- -- 24 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

ngps@ngps-jetson-2:~$ i2cget -y 10 0x24 0x05
0x00
ngps@ngps-jetson-2:~$ i2cget -y 10 0x24 0x06
0x00
ngps@ngps-jetson-2:~$ i2cget -y 10 0x24 0x07
0x00

So 0x24 is detected fine but the date registers are all zero. I still can’t find any datasheet that explains these registers for the HAT.

OK, 0x24 responding on bus 10 confirms the I2C path itself is working, so this isn’t a wiring problem. The empty date registers are a red flag though.

Can you also paste the output of your pipeline when you actually try to stream? Something like:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! ‘video/x-raw(memory:NVMM),width=1920,height=1080,framerate=60/1’ ! nvvidconv ! nvoverlaysink

And let me know which driver is currently bound - the Arducam IMX477 stereo driver or the stock NVIDIA one.

Here’s the 1920x1080 run. I had it set up with SENSOR_ID and FRAMERATE vars:

# SENSOR_ID=0   # 0 for CAM0 and 1 for CAM1 ports
# FRAMERATE=60   # Framerate can go from 2 to 60 for 1920x1080 mode
gst-launch-1.0 nvarguscamerasrc sensor-id=$SENSOR_ID ! "video/x-raw(memory:NVMM),width=1920,height=1080,framerate=$FRAMERATE/1" ! nvvidconv ! nvoverlaysink

and the errors were:

nvbuf_utils: Could not get EGL display connection
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 4056 x 3040 FR = 10.000000 fps Duration = 100000000 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 2028 x 1520 FR = 40.000000 fps Duration = 25000000 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 2028 x 1080 FR = 50.000000 fps Duration = 20000000 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
ARGUS_ERROR: Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute: 880 Frame Rate specified is greater than supported
ARGUS_ERROR: Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute: 1100 InvalidState.
ERROR: from element /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0: CANCELLED
Argus Error Status
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
nvbuf_utils: Can not get HW buffer from FD... Exiting...
CONSUMER: ERROR OCCURRED

No live feed at all.

Two separate things stand out there. The ‘Frame Rate specified is greater than supported’ at 60fps is expected - look at the mode list, 1920x1080 isn’t even a mode on this sensor; the supported modes are 4056x3040@10, 2028x1520@40, and 2028x1080@50, so 60fps was never going to fly.

The more important one is ‘nvbuf_utils: Can not get HW buffer from FD’ followed by CANCELLED - that’s the actual stream failure.

Can you try the native mode 4056x3040 and paste the whole log? Also confirm which sensor driver is loaded, because the mode list in that capture looks like the Arducam driver.

Here’s the 4056x3040 capture with the Arducam IMX477 driver:

nvbuf_utils: Could not get EGL display connection
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 4056 x 3040 FR = 10.000000 fps Duration = 100000000 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 2028 x 1520 FR = 40.000000 fps Duration = 25000000 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 2028 x 1080 FR = 50.000000 fps Duration = 20000000 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: Running with following settings:
   Camera index = 0
   Camera mode  = 0
   Output Stream W = 4056 H = 3040
   seconds to Run    = 0
   Frame Rate = 10.000000
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
nvbuf_utils: Can not get HW buffer from FD... Exiting...
CONSUMER: ERROR OCCURRED
ERROR: from element /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0: CANCELLED
Argus Error Status
Execution ended after 0:00:02.855040305

I’ve installed/reinstalled the Arducam stereo driver via install_full.sh -m imx477_stereo, and before that I did sudo dpkg -r arducam-nvidia-l4t-kernel. Same result.

To add to the above - I also tried the NVIDIA-provided IMX477 driver earlier and got basically the same failure, just with a different sensor mode list (sensor detected as 4032 x 3040 FR = 12.999999):

GST_ARGUS: 4032 x 3040 FR = 12.999999 fps Duration = 76923080 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 1920 x 1080 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 2592 x 1944 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 2560 x 1440 FR = 40.000000 fps Duration = 25000000 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: Running with following settings:
   Camera index = 0
   Camera mode  = 0
   Output Stream W = 4032 H = 3040
   Frame Rate = 12.999999
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
nvbuf_utils: Can not get HW buffer from FD... Exiting...
CONSUMER: ERROR OCCURRED
ERROR: from element /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0: CANCELLED

Then I went back to the Arducam driver. Same thing. I also tried setting the HAT register directly:

i2cset -y 10 0x24 0x24 0x01
i2cset -y 10 0x24 0x24 0x02

and re-ran the pipeline - identical Argus errors, except in one of the runs it said DISCONNECTED instead of CANCELLED. I also tried a single-frame capture to a JPEG:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 num-buffers=1 ! ‘video/x-raw(memory:NVMM),format=(string)NV12, width=(int)4056, height=(int)3040,framerate=10/1’ ! nvjpegenc ! filesink location=arducam-test.jpg

Same failure. I’ve checked all the wiring/ribbon cables multiple times too.

This is really useful - thanks for being thorough. Two entirely different drivers (the NVIDIA IMX477 and the Arducam IMX477 stereo one) both fail at the same point with ‘Can not get HW buffer from FD’, and i2cdetect clearly shows 0x24 answering on bus 10. Combined with the mode lists you posted, the Jetson is talking to the sensor, but the stream never starts.

The piece that keeps jumping out at me is the HAT date registers reading all 0x00, while the HAT at 0x24 is definitely reachable. That combination - working I2C plus empty date registers - is exactly what you’d see on the older HAT firmware.

Can you confirm once more the exact register readback, just so I’ve got it clean in the thread?

Yep, here it is again, straight off the board:

ngps@ngps-jetson-2:~$ i2cdetect -r -y 10
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- --
20: -- -- -- 24 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

ngps@ngps-jetson-2:~$ i2cget -y 10 0x24 0x05
0x00
ngps@ngps-jetson-2:~$ i2cget -y 10 0x24 0x06
0x00
ngps@ngps-jetson-2:~$ i2cget -y 10 0x24 0x07
0x00

Still all zero. Kernel is 4.9.253-tegra if that matters.

Thanks - that confirms it. I think we’ve found the root cause.

Based on the register readback you posted, your HAT is running the older firmware. The time-setting / firmware-date feature was only added in the latest firmware, so on the old firmware those date registers (0x05, 0x06, 0x07 on 0x24) are simply not populated - that’s why they all read 0x00. The fact that 0x24 is detected on bus 10 means your I2C wiring and the HAT communication are fine, so this is a firmware issue, not a hardware or cabling problem. That also lines up with the identical failure across both the Arducam and NVIDIA IMX477 drivers and all the hardware swaps you went through.

The catch is that this firmware can’t be reflashed from the Jetson over I2C - the upgrade has to be performed by Arducam, which means the HAT boards need to be sent back in to be updated. So the conclusion here is: old firmware on the HAT, fixable only via an Arducam firmware upgrade. Get in touch and we’ll sort out getting your units updated.