Hi everyone, hoping someone here can help. I’m using an Arducam 5MP Plus OV5642 SPI camera (the Arducam Mini module) on an NXP platform running a real-time OS. What I really need is to capture 10-bit RAW images. The product page says 10-bit RAW is supported, but I honestly can’t find any documentation that explains how to actually configure it. I’ve been going off the Arducam instructions and the OmniVision datasheets, but neither seems to cover the register setup I need. The weird thing is it did work at some point, but now it’s quit working. Any pointers on which registers to change, or a more detailed datasheet, would be really appreciated.
Happy to help dig into this. A few things would help me understand where you’re at: which firmware/library are you using to drive the camera over SPI, and how is it wired to your NXP board (which SPI peripheral, clock speed)? When you say it ‘quit working’, does it return no data at all now, or does it still stream but the images come out wrong? And are you able to do a register read/write at all right now (i.e. can you read back a known register like the chip ID)? In the meantime there’s some reference material here: Arducam Wiki and the community forum https://www.arducam.com/forums/. But if you can share a register dump from a working vs non-working state, that’ll speed things up a lot.
Thanks. Right now I can still talk to the sensor - I can read registers back, so the SPI link seems alive. It’s the capture that’s the problem - I’m basically getting garbage / not the format I expect. The 10-bit RAW is the whole reason we picked this part, it’s advertised but I can’t find the register config for it anywhere. I’ve tried following the OV5642 datasheet format registers but nothing matches what I’d expect. To be honest I’m not even sure which registers control the RAW8 vs RAW10 output on this module, since Arducam wraps the OV5642 with their own SPI bridge.
Got it, that helps. The key thing here is that the Arducam Mini doesn’t expose every OV5642 register directly - some of them are managed by the on-board SPI bridge, so setting the sensor’s own format register alone may not change what actually comes out of the SPI bus. For the sensor side, the output format is selected in the format control register 0x4300 (bits [7:4] select the output format, e.g. RAW10 vs RAW8), and there’s also the ISP input format at 0x501F and related registers. But you also need the Arducam bridge configured to expect the matching data length, because RAW10 packs the pixel data differently than RAW8 - if the bridge’s burst read length doesn’t match, you’ll get exactly the kind of garbage you’re describing. Can you tell me: (1) what value you’re writing to 0x4300? (2) what burst/read length your SPI code is requesting? (3) what clock speed the SPI bus is running at? That’ll tell us whether it’s a format mismatch or a bus-length mismatch.
OK I checked - I was writing 0x4300 but I’m not 100% sure the bridge is set up for the longer read length. When I bump the read length I get a mess, and when I don’t, the image looks like it’s interpreting the data wrong (looks like 8-bit the way it’s coming out). So maybe it’s the length/packing thing you mentioned. I’ll try matching the burst length to the 10-bit packed format and see. Is there a specific recommended sequence for switching the OV5642 into RAW10 on the Mini, or a register table? That’s really what I’m missing.
No single clean table for this that I can hand over, unfortunately - which is kind of the problem you’re hitting. The general flow is: set the sensor’s format registers for RAW10 (0x4300 and the ISP format registers), then make sure the bridge is told the pixel output is 10-bit so it reads the right number of bytes, then adjust your capture/decode code to unpack 10-bit (or 8-bit) accordingly. If the bridge and the sensor disagree on format, you get the shifting/interpretation problems. One caution: since you mentioned it used to work and then stopped, I’d double-check that nothing in your init sequence changes the format register after startup, and that the SPI clock isn’t too high for reliable transfer - timing issues on SPI often show up as intermittent garbage.
Still haven’t heard back from engineering on the 10-bit RAW config, so following up here. Two things now:
- Still no proper documentation for getting 10-bit RAW out of this module.
- I’m also getting problems with RAW images in 8-bit color. The pixels seem to shift from time to time - I don’t know what causes it, but it wrecks the debayering. In the image you can see it as color shifts.
Here’s what it looks like: https://cdn.arducam.com/forum/b70c6e1ca24bf85bec147795951d1ac5/image001.png
Is there a config I could try, or any idea why this might be happening? Happy to share my init sequence and a register dump.
Thanks for the image, that’s helpful. Those color shifts / intermittent pixel shifts usually point to one of a few things rather than the debayer code itself: SPI clock too high or marginal, so bytes occasionally drop/shift between frames; the bridge read length not matching the actual pixel format (so line boundaries drift); or a register that gets rewritten after init (or the sensor resetting mid-stream). Since it worked before and now doesn’t, I’d suspect a timing/bus reliability issue more than the format config itself. Can you post your full init register sequence, the SPI clock speed, and a register dump taken right after init and again after the first frame? With that we can tell whether a register is drifting or whether it’s a bus/timing problem.
Here’s what I’m doing: I init the OV5642 with a sequence from the datasheet, set the format registers, then loop reading frames over SPI. The clock is fairly high (I’ll paste the exact value below). I took a dump at init vs after the first frame - a couple registers differ after the first frame but I’m not sure if that’s expected. I’ll paste the sequence and clock speed. Honestly at this point the two unsolved things are: how to correctly get 10-bit RAW out, and why the pixels shift in 8-bit color.
OK, here’s where we are. Two separate issues, and neither is fully solved yet.
-
10-bit RAW: there’s no public step-by-step register table for the Mini + OV5642, which is why you’re stuck. It’s really a combination of the sensor format registers (0x4300 and the ISP format registers) plus matching the Arducam bridge’s expected data length and your unpacking code. If the bridge length and the sensor format don’t match, you’ll keep getting the garbage you saw.
-
The shifting pixels / color shifts: most likely a timing or bus-format mismatch rather than your debayer code - SPI clock too high, or the read length not matching the pixel format, causing line boundaries to drift. The fact that a couple registers differ after the first frame is worth chasing - if a register is being rewritten, that could explain the intermittency.
Workaround in the meantime: drop the SPI clock and lock the read length to a single known format (RAW8) and confirm stable frames before moving to RAW10. If you can post the full init sequence, the clock speed, and the before/after register dumps, we can narrow down whether it’s register drift or a bus-timing issue. I’ll also check whether engineering can share a proper RAW10 config, but for now treat 10-bit RAW as unconfirmed until we match the bridge length to the sensor format.