Arducam IMX477 12MP camera displays red/black image on Jetson Nano but works on Pi 4

Hi all, I’m stuck with an Arducam IMX477 12MP camera on a Jetson Nano Developer Kit (4GB). The weird part is the exact same camera works on my Raspberry Pi 4, but on the Nano it has never worked. I followed the native camera quick start guide here: Quick-Start-Guide - Arducam Wiki and installed the driver as it says. Has anyone seen this before?

Hi, can you paste the exact commands you ran to install the driver and the output? Also run dmesg | grep imx477 after a fresh boot and post what it prints. That’ll help us see whether the sensor is probing correctly on the Nano.

Sure. Here’s what I ran:

wget https://github.com/ArduCAM/MIPI_Camera/releases/download/v0.0.3/install_full.sh
chmod +x install_full.sh
./install_full.sh -m imx477

Output was basically:

./install_full.sh: line 19: warning: command substitution: ignored null byte in input
NVIDIA Jetson Nano Developer Kit

It downloaded modules.txt, imx477_links.txt, and arducam-nvidia-l4t-kernel-t210-4.9.253-tegra-32.7.1-20220316013810_arm64_imx477.deb, then installed arducam-nvidia-l4t-kernel (4.9.253-tegra-32.7.1-20220316013810). I rebooted after that. File sizes: install_full.sh 4560 bytes, modules.txt 1214 bytes, imx477_links.txt 11811 bytes, and the .deb was 8174068 bytes. The only odd thing was that “ignored null byte in input” warning.

Thanks. The null byte warning from the script is usually harmless, and the driver package looks like it installed. Next, can you run dmesg | grep imx477 after a reboot and paste the output?

Here’s the output:

[ 1.298719] imx477 7-001a: tegracam sensor driver:imx477_v2.0.6
[ 1.600466] imx477 8-001a: tegracam sensor driver:imx477_v2.0.6
[ 1.900822] imx477 8-001a: imx477_board_setup: error during i2c read probe (-121)
[ 1.908555] imx477 8-001a: board setup failed
[ 1.913033] imx477: probe of 8-001a failed with error -121
[ 2.092769] vi 54080000.vi: subdev imx477 7-001a bound

I see one imx477 at 7-001a bound, but the 8-001a one fails with error -121.

Right, the key part is this: imx477 8-001a tries imx477_board_setup and fails on an i2c read probe with -121, so board setup fails and that device never probes. Only imx477 7-001a binds to vi 54080000.vi. That usually means one of the sensor channels isn’t responding. Let’s see if you still get a picture out of the working side. Can you run this and tell me what the preview looks like?

SENSOR_ID=0
FRAMERATE=30
gst-launch-1.0 nvarguscamerasrc sensor-id=$SENSOR_ID ! "video/x-raw(memory:NVMM),width=1920,height=1080,framerate=$FRAMERATE/1" ! nvvidconv ! nvoverlaysink

If you can grab a photo of the screen when the bad image shows up, that’d help too.

I ran it with SENSOR_ID=0 and FRAMERATE=30. Full output:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 4032 x 3040 FR = 29,999999 fps Duration = 33333334 ; Analog Gain range min 1,000000, max 22,250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 3840 x 2160 FR = 29,999999 fps Duration = 33333334 ; 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: Running with following settings:
Camera index = 0
Camera mode = 2
Output Stream W = 1920 H = 1080
seconds to Run = 0
Frame Rate = 59,999999
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:01:36.490190138
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
GST_ARGUS: Cleaning up
CONSUMER: Done Success

The preview comes up but it’s a mess, I’d call it a drizzle of red/black image, not a real picture. It ran for about 1:36 before I Ctrl+C’d it.

Thanks for the log. The pipeline does enumerate the sensor modes (4032x3040, 3840x2160, 1920x1080) and starts captures, so the driver side is partially alive, but the frame content is corrupted. Could you upload a couple of photos of what’s on screen? There’s also a troubleshooting page here Troubleshooting - Arducam Wiki and a video walkthrough here https://www.youtube.com/watch?v=5R4Qcwj8uto in case something in there jumps out.

Here are the photos showing the red/black drizzle (attached). Since the same camera works on the Pi 4, I’m starting to wonder if this is a hardware issue on the Nano side. Is there any deeper driver debug I can run? I’ve already looked through the troubleshoot page and that YouTube video.

Before we go deeper, let’s try removing the digital denoise path, since that red/black drizzling can be ISP noise. Try this:

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

The ispdigitalgainrange="1 1" locks the ISP digital gain to 1 so it doesn’t boost the noise, and I set the framerate to 21/1. Let me know what the preview looks like with that.

I tried the denoise command. The heavy noise seems to be gone, but now the output is basically dark, it just shows light variations, like it’s capturing brightness changes but no actual image. I even swapped the lens to double-check and the original lens itself is fine. I attached two short videos showing what I mean.

Thanks, the videos were the key. The denoise command did its job, that noise is gone. What you’re seeing now is a dark preview because the lens aperture is closed/stopped down, not a sensor or driver fault. Open/adjust the aperture on the C/CS-mount lens and the image should come up. There’s a quick guide on those lenses here: https://www.arducam.com/raspberry-pi-high-quality-camera-c-cs-mount-lens/ . So to sum up: the original red/black drizzle was fixed by locking the ISP digital gain, and the remaining dark preview was just the closed aperture. Try opening it up and let us know if it clears.