STM32N6570-DK + IMX335: LCD output shows a corrupted pattern

[BCPH357]

Hello ST team,

I am developing a camera application on STM32N6570-DK + IMX335.
The entire capture/display pipeline follows the official DCMIPP_ContinuousMode example:

IMX335 RAW10 → CSI → ISP → PixelPacker RGB565 → LTDC

However, the LCD output shows a corrupted pattern like in the attached video:

The image reacts to hand movement (so the sensor is streaming), but the content becomes color-shifted, diagonal, and distorted. The pattern matches the behavior when:

RAW10 is fed directly into the PixelPacker interpreted as RGB565,

meaning the ISP output is never routed to Pipe1.

What currently works

1. IMX335 is clearly streaming (image brightness changes when covering the lens).

2. CSI + Pipe1 receive real frames.

3. LTDC and framebuffer work correctly (solid-color test OK).

4. All registers after DCMIPP init match the official demo.

5. ISP_Init() and ISP_Start() both return OK (0).

6. ISP_BackgroundProcess() also returns OK.

What is incorrect

After ISP_Start(), the register dump is:

P1SRCR = 0x00000000
P1PPCR = 0x00000001
P1DMCR = 0x64420001
P1CCCR = 0x00000000
P1GMCR = 0x00000001
CMSR1 = 0x00800003

The only abnormal register is P1SRCR = 0,
which means:

ISP output is not routed into Pipe1

PixelPacker receives RAW10 directly

Result = diagonal rainbow-like color artifacts (matches the video)

This suggests ISP pipeline is not being activated internally, even though ISP_Start() returns OK.

Important detail about ISP IQ configuration (AEC/AWB)

In the ISP IQ configuration (imx335_E27_isp_param_conf.h),
I temporarily disabled:

.AECAlgo.enable = 0; .AWBAlgo.enable = 0;

because if I set them to 1 (enabled), ISP_Init() fails with:

ISP error: ERROR CODE = 190

So to avoid ISP_Init failure, I had to disable both.
This may indicate that some ISP pipeline block is not configured correctly,
and ISP may be silently skipping the routing stage even after ISP_Start() returns OK.

Could this be related to why ISP → Pipe1 routing is never activated?

 My questions for ST

1. Under what conditions would ISP_Start() return OK
   but ISP routing (P1SRCR) remains at 0x00000000?

2. Does disabling AEC/AWB break any dependency in the IMX335 RAW10 → RGB565 pipeline,
   leading to ISP skipping the activation of demosaic/color stages?

3. What does ISP error 190 specifically correspond to in the N6 ISP middleware?

4. Is there any required IQ table parameter that must be enabled for ISP routing to Pipe1?

5. Could this be caused by a mismatch in the IMX335 RAW10 mode table?
   (Although I already restored the resolution table and mode table from the official example.)

Summary of the issue

1. Sensor is streaming (RAW10 frames present).

2. LTDC works.

3. DCMIPP configuration matches official sample.

4. ISP_Init() / ISP_Start() report success.

5. But ISP routing never happens → .P1SRCR = 0

6. PixelPacker receives RAW10 instead of ISP RGB output → diagonal colored artifacts.

Video attached shows the exact behavior.

Any guidance to help identify why ISP routing does not activate (and why AEC/AWB cause error 190) would be greatly appreciated.

Thank you very much!

[Simon V.]

Hello,

Please find preliminary analysis :

Pipeline we expect to use >>
IMX335 (RAW10) -> CSI/DCMIPP -> ISP (demosaic + color) -> PixelPacker RGB565 -> LTDC

What we actually see >>>
The LTDC shows diagonal, color-shifted patterns that look exactly like RAW10 data being interpreted as RGB565.
This means Pipe1 is probably receiving RAW10 directly, not the RGB output of the ISP.

Important registers (after calling ISP_Start())
P1SRCR = 0x00000000 <- routing from ISP to Pipe1 is OFF
P1PPCR = 0x00000001 <- PixelPacker is ON (probably in RGB565 mode)
P1DMCR = 0x64420001 <- demosaic block seems enabled
P1CCCR = 0x00000000 <- color correction OFF
P1GMCR = 0x00000001 <- gamma block barely enabled
CMSR1 = 0x00800003 <- CSI/Camera shows that data is coming in

Conclusion:
Even if some ISP blocks are configured, the route switch P1SRCR never changes to "ISP to Pipe1".
That perfectly matches the RAW10-looking artifacts on the LTDC.

Likely root causes

1. Missing blocks in the ISP graph
   Many ISP pipelines require a complete chain and at least one active output (memory writer or display).
   If any required stage is missing (for example demosaic -> color -> packer), the ISP may stay in a "configured but not active" state, leaving P1SRCR at zero.

2. Wrong input format or data type
   If CSI2 Data Type or Virtual Channel do not match what the ISP expects, the ISP will refuse to validate frames.
   Frames may still pass through the bypass path and reach the packer as RAW.

3. Clock or bandwidth problems
   If ISP clock is too low or AXI bus is overloaded, the ISP may refuse to enable the route or may drop back to a safe mode.

4. Security or domain issues
   If Pipe1 or the ISP writer belongs to a protected domain, route activation might silently fail.

5. IQ / statistics preconditions
   Your "error 190" on AEC/AWB usually means stats are not valid or some required block is disabled.
   If stats or color domain are wrong, some middleware layers refuse activation.

Notes about your registers
P1DMCR = 0x64420001 shows that demosaic is configured, but that does not prove that the route is active.
P1CCCR = 0x00000000 means color conversion is off.
But for RAW10 -> RGB565 you normally need this path:

RAW10 -> demosaic -> color conversion (RGB888) -> packer (RGB565)

If color conversion is off, the packer may still be fed with RAW10.
P1SRCR = 0x00000000 is the key indicator: the route is not active.

Simple tests to narrow the issue

1. Force the minimum valid RGB chain
   Enable demosaic + color conversion to produce RGB888.
   Send that to a memory writer, then enable Pipe1.
   If P1SRCR flips to a nonzero value, then your original graph was incomplete.

2. Test PixelPacker with a known RGB input
   Configure the packer input to RGB888 from the ISP.
   If the artifacts disappear, you confirm that the previous mode was feeding RAW10 to the packer.

3. Try a smaller resolution and frame rate
   For example 640x480 at 15 fps.
   If the ISP route activates, then you may have a bandwidth or clock issue.

4. Enable stats but disable AEC/AWB
   Make sure histogram and RGB stats blocks output nonzero values.
   If stats are zero, AWB and AEC will fail.

5. Double-check CSI2 data type
   Use DT = RAW10 (usually 0x2B) and make sure VC matches the ISP input.
   Check for CRC, ECC, FIFO errors on CSI.

Regards,

Simon