I’m having a frustrating issue with my ArduCam B0477 (20MP IMX283 USB 3.0 camera module with 16mm C-Mount lens). The camera streaming works perfectly fine during the day, but if I leave it running overnight, by morning the feed turns into a black or green mess and the ROS2 node process dies. It tries to restart itself but keeps failing.
A power cycle (unplug/replug USB) fixes it temporarily, but that’s not viable — this is deployed remotely.
Environment:
Camera: Arducam B0477 (USB3 20MP), connected via Lenovo USB-C to USB-A cable
Video device: /dev/v4l/by-id/usb-Arducam_Arducam_B0477__USB3_20MP__Arducam_20220908_0001-video-index0
[ERROR] [usb_cam_node_exe-12]: process has died [pid 407172, exit code -6, cmd '/release/install/lib/usb_cam/usb_cam_node_exe --ros-args -r __node:=arducam -r __ns:=/arducam'].
[INFO] [usb_cam_node_exe-12]: process started with pid [407222]
[usb_cam_node_exe-12] [INFO] [1763048727.827449974] [arducam.arducam]: camera_name value: arducam
[usb_cam_node_exe-12] [WARN] [1763048727.827511347] [arducam.arducam]: framerate: 20.000000
[usb_cam_node_exe-12] [INFO] [1763048727.829583738] [arducam.arducam]: Starting 'arducam' (/dev/video0) at 2720x1536 via mmap (yuyv) at 20 FPS
After the failure, ls /dev/video* still shows the device and v4l2-ctl --all reports everything normally — driver, format (2720x1536 YUYV), controls all look correct. But the stream is dead (black/green frame).
Here’s what the failed image looks like:
Has anyone seen this kind of overnight degradation with the B0477?
Thanks for the detailed report — that really helps narrow things down.
Looking at your logs and symptoms, this looks like a firmware-level instability on the B0477. The pattern you’re seeing (works fine for hours, then the stream corrupts to black/green and the usb_cam node crashes with exit code -6, but the USB device itself stays visible to the kernel) points to the camera’s onboard firmware losing sync or entering a bad state after extended operation. A power cycle resets the firmware, which is why unplug/replug brings it back.
The uvcvideo driver is still holding the device node, so from the OS perspective everything looks present — that’s consistent with the firmware on the camera side going sideways rather than a USB bus disconnect.
I have a firmware update package for the B0477 that addresses stability issues like this. I’ve sent you the download link in a private message — please check your inbox and follow the instructions in the package to flash it.
Thanks for the quick response. That explanation makes sense — firmware going into a bad state while the UVC layer stays alive would explain why v4l2-ctl still sees everything normally.
I’ve got the firmware package. I won’t be able to test until next week, but I’ll report back once I’ve flashed it and let it run overnight.
Okay, so I applied the firmware update — and unfortunately things got worse, not better.
Now when I start streaming, instead of working normally and degrading over time, I immediately get a bright green image capture, then the node closes and reopens in a continuous loop. It never stabilizes at all.
Also, I’m a bit confused: the uvcvideo driver version still shows as 6.14.0 after the firmware flash. Is that expected? How can I actually verify what firmware version is on the camera itself? I want to confirm the update even took.
That’s not the outcome we were hoping for. The bright-green-then-restart-loop behavior suggests the firmware flash either didn’t apply correctly or introduced a new issue.
To answer your question about verification: the uvcvideo driver version (6.14.0) is the kernel’s USB Video Class driver — it’s a standard system component, not something Arducam ships. A camera firmware update will never change that number, so that’s not how you verify the flash. What you want to look at is the camera’s own serial/identifier string, which is what appears in the /dev/v4l/by-id/ symlink path. If the firmware actually took, you should see that identifier change.
At this point I think we need to look at this directly. I’ve sent you the details for a remote support session via private message — please check there and we’ll get this sorted out.
Quick update — I went ahead and reflashed the firmware again over the weekend, and this time it seems to have taken properly. The camera has been streaming stable for over 48 hours now, no green frames, no crashes.
One thing I noticed: after the second flash, the device by-id path changed. It used to be:
Now it shows a 2025 date in the serial instead of 20220908. Is that the actual indicator that the firmware update was applied correctly? The uvcvideo driver still says 6.14.0, but I’m guessing that’s unrelated (as you mentioned earlier).
That’s great news — and yes, you’ve hit on exactly the right verification method.
The by-id change from Arducam_20220908 to a 2025xxxx-style serial is the definitive sign that the firmware update was successfully applied. That serial string comes from the camera’s firmware, so the date bump tells you the new firmware image actually flashed correctly to the device.
Just to reiterate for anyone else who runs into this: the uvcvideo driver version (6.14.0 in your case) will never change with a camera firmware update. uvcvideo is the kernel’s generic USB Video Class driver — it’s not an Arducam-specific driver. It handles any UVC-compliant device and its version is tied to your Linux kernel, not to the camera. The camera’s firmware is separate and lives on the device itself. The by-id path / serial string is what reflects the firmware identity.
So to summarize your case: the first flash likely didn’t take properly (or was interrupted), which caused the green-screen restart loop. The second flash applied correctly, confirmed by the serial date change, and the overnight streaming issue is now resolved. Glad it’s working!
