Hey everyone, we’re seeing a sharp increase in defective IMX477 camera modules across our deployments and we’re struggling to pin down the root cause. Initially we suspected it might be related to unsafe handling by our assembly partner (non-ESD-safe workspace) or possibly moisture intrusion at customer sites in the field. Has anyone else seen a spike in failures with these modules recently?
That sounds frustrating. Before we dive deeper, could you narrow things down a bit? Are you seeing this across all units or only on a specific hardware revision? And what software stack are you running — kernel version, OS, that sort of thing? That’ll help a lot in isolating where to look.
So we’ve done some digging and we’ve been able to pin this down quite specifically now. The issue only affects the UC-698 Rev.D hardware revision, and it only started happening after we updated our kernel from 5.15 to 6.12. On kernel 5.15 with the same Rev.D boards, everything works fine. I’ve put together a detailed breakdown of our findings in the attached form:
Arducam_Technical_Support_Form.xlsx
Basically: UC-698 Rev.D + kernel 6.12 = failures. Same hardware on 5.15 = no issues. This seems pretty consistent across all our affected units.
Thanks for the detailed breakdown — that narrows things down massively. We’ve been reviewing this internally and our current thinking is that kernel 6.12 may not be fully stable yet with these camera modules; it’s likely still going through upstream testing and validation. Since you’ve confirmed the modules work correctly on kernel 5.15, that essentially rules out a hardware defect on the Rev.D boards themselves. The incompatibility looks to be entirely on the kernel side.
Quick update: we’ve confirmed that the root cause is an incompatibility between the UC-698 Rev.D camera modules and kernel 6.12. We suspect a kernel-side instability — possibly something in the V4L2 or driver subsystem that changed between 5.15 and 6.12 that the module’s driver stack isn’t handling correctly yet. A fix is in progress but it’s not available right now.
In the meantime, the workaround is straightforward: revert to kernel 5.15 for both your own testing and for any end users who are affected. I know that’s not ideal if you’ve already rolled out 6.12 widely, but it’ll keep things operational while we get the proper fix sorted.
That makes sense, and reverting to 5.15 works for now. I’ve got several affected UC-698 Rev.D modules here — happy to send a batch your way if it’ll help with reproduction and testing on your end. Just let me know where to ship them.
Appreciate the offer — I’ve sent you the shipping details in a private message. Please check your messages and we’ll get those modules in hand for testing.
On our side, we’ve started trying to reproduce this. So far we’ve tested streaming from UC-698 Rev.D hardware on a Raspberry Pi OS setup running kernel 6.12.20-v8, and the stream came up without any issues. We then bumped up to kernel 6.12.25-v8 to see if it was version-specific, but that also worked fine. We’re not able to trigger the failure on our side yet.
One important thing to note: we noticed from your form that you’re running a Yocto-based OS rather than the standard Raspberry Pi OS. That could be a significant variable here — Yocto builds can have different kernel configs, different versions of userspace libraries (like libcamera or the Media Controller API bits), and different device tree overlays compared to a stock Raspberry Pi OS image. The incompatibility might only surface under your specific Yocto environment, which would explain why we can’t reproduce it on our standard test setup.
Good point about the Yocto vs Raspberry Pi OS difference — that could definitely explain the gap. I’m going to spin up a stock Raspberry Pi OS image on one of our setups with the UC-698 Rev.D and kernel 6.12 and see if the issue reproduces there. If it doesn’t, then the problem is almost certainly something in our Yocto kernel configuration or device tree. I’ll report back with what I find.