DCMIPP PIPE1 reports continuous successful frame capture (CPTACT=1, LSTFRM toggling, no OVRF) but pixel payload is frozen and scene-independent

[yasiralismbr]

Board: STM32N6570-DK Sensor: Sony IMX219 (Raspberry Pi Camera Module 2 / NoIR), custom driver, connected via a 15-pin-to-22-pin adapter cable into the board's camera connector (normally used for the MB1854/IMX335 module)

Summary

I've written a from-scratch IMX219 driver (I2C register map transcribed from the Linux kernel's imx219.c) as an additive sensor option alongside the working IMX335 path. I2C control, power sequencing, and CSI-2 D-PHY link all come up healthy. DCMIPP's own status registers report that PIPE1 is continuously and successfully capturing new frames. But the actual pixel data written to memory is frozen — bit-for-bit identical — and does not respond to real scene changes. I'm looking for insight into what could produce this specific disconnect.

Configuration

• 2 CSI-2 lanes, D-PHY bitrate bucket DCMIPP_CSI_PHY_BT_900 (900 Mbps bucket, closest available to the computed 912 Mbps for this PLL config)
• Sensor PLL: VTPXCK_DIV=5, PREPLLCK_VT_DIV=3, PLL_VT_MPY=57, OPSYCK_DIV=1, PREPLLCK_OP_DIV=3, PLL_OP_MPY=114 at 24 MHz self-clock (matches the kernel driver's 2-lane table)
• Mode: 2x2-binned 1640x1232, RAW10, RGGB Bayer
• CSI VC config: DCMIPP_CSI_SetVCConfig(..., DCMIPP_VIRTUAL_CHANNEL0, DCMIPP_CSI_DT_BPP10), DataTypeIDA = DCMIPP_DT_RAW10
• PIPE1: ISP decimation (factor-1 pass-through) + HAL_DCMIPP_PIPE_EnableISPRawBayer2RGB (RGGB, strength 8) → RGB565 output to an 800x480 display buffer
• CMW_MODE_CONTINUOUS capture mode via HAL_DCMIPP_CSI_PIPE_Start

Symptom, precisely

The display buffer (triple-buffered, DISPLAY_BUFFER_NB=3) is memset to 0 at startup. After streaming starts, it becomes non-zero with a plausible-looking pixel value range (min=8, max=130 across the full 800x480x2-byte buffer, sampled every 7 bytes). That part looks like a real captured frame. But from that point on:

• The byte content never changes again — confirmed by printing min/max and the first 8 raw bytes every ~1s for minutes at a time; identical every single sample.
• Covering and uncovering the lens for a continuous ~6000+ frame span produced zero change in any sampled value.
• Re-writing the sensor's MODE_SELECT streaming-enable register every 60 frames (1000+ times) had zero effect.
• Disabling the PIPE1 ISP Bayer2RGB demosaic block entirely (raw pass-through) produced identical bytes to the demosaic-enabled case.
• Disabling the PIPE1 ISP decimation block as well (both ISP blocks off) still produced the identical bytes.

Meanwhile, DCMIPP's own status registers say everything is fine throughout:

• P1SR = 0x00800007 / 0x00820007 alternating — CPTACT (bit 23) = 1, LINEF/FRAMEF/VSYNCF all set, and LSTFRM (bit 17) visibly toggles between reads, which I'd expect only if hardware is completing distinct new frames each time.
• OVRF (overrun, bit 7) is never set.
• P1PPM0AR1/P1CPPM0AR1 (programmed/current pixel-packer memory address) do rotate through the three buffer addresses as expected from our frame-complete IRQ reprogramming the DMA target each frame.

So: address rotation happens, frame-complete/status flags toggle, no error flags — but the payload is static and disconnected from the physical scene.

Question

What could cause DCMIPP to report healthy, continuous, successful frame completion while the actual transferred pixel data never changes regardless of scene content? Specific things I'd appreciate input on:

1. Is this consistent with a D-PHY bit-sampling/alignment issue that locks "stably" but at a wrong sample point (producing consistent-but-wrong decoded bytes rather than random garbage or a failure to lock)?
2. Could this be explained by DCMIPP capturing CSI-2 "embedded data" lines (a different datatype some sensors send alongside RAW10 image lines) instead of the actual image payload, if our virtual-channel/datatype filter is subtly misconfigured? If so, what's the correct way to explicitly exclude/select datatypes on DCMIPP's CSI RX for a sensor that may emit multiple line types?
3. Any known erratum or internal-memory/FIFO enablement requirement specific to PIPE1's raw capture path (separate from the documented AXISRAM3-6 power-down-by-default behavior, which we already handle) that could produce this "capture completes, payload doesn't update" pattern?

Happy to share full register dumps, our driver source, or a logic analyzer capture of the CSI lines if that would help narrow this down.