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 intended

IMX335 (RAW10) → CSI/DCMIPP → ISP (demosaic + color) → PixelPacker RGB565 → LTDC

Observed behavior

• LTDC shows diagonal, color‑shifted artifacts that look exactly like RAW10 misinterpreted as RGB565.
• Therefore Pipe1 is receiving RAW10 directly, not the ISP‑processed RGB.

Key registers (after ISP_Start():(

P1SRCR = 0x00000000   ← routing from ISP to Pipe1 **disabled**
P1PPCR = 0x00000001   ← PixelPacker enabled (likely in RGB565 mode)
P1DMCR = 0x64420001   ← Demosaic control register shows enabled bits
P1CCCR = 0x00000000   ← Color correction disabled?
P1GMCR = 0x00000001   ← Gamma (?) enabled minimal
CMSR1  = 0x00800003   ← Camera/CSI status indicates stream present

Conclusion: The ISP sub‑blocks may be configured, but the route switch (P1SRCR) never flips to “ISP → Pipe1”. That explains the artifacts perfectly.

---

:direct_hit: Likely root‑cause categories

1. Graph completeness / sink validity

• Many ISP pipelines require a valid, fully connected graph and at least one active sink (e.g., memory writer or display path) before the route switch is armed.
• If any mandatory block is missing (e.g., demosaic → color conversion → packer) or an IQ dependency isn’t met, the pipeline can stay in a “configured but not activated” state, leaving P1SRCR at 0.

2. Input format / DT mismatch

• If CSI‑2 Data Type (DT) or Virtual Channel (VC) doesn’t match what the ISP input expects, the ISP won’t mark frames valid and it won’t route to Pipe1. Frames still appear to reach the pixel packer as RAW (bypass path).

3. Clocking / bandwidth / AXI QoS

• If ISP clock is below minimum, or AXI QoS for camera/ISP masters is starving, the pipeline may refuse activation or immediately fallback. You’ll still see streaming in CSI/DCMIPP, but the ISP route never goes active.

4. Security / partitioning

• On N6 with secure / non‑secure partitions, if the ISP writer (or Pipe1) is in a domain that lacks permissions to write/read, the activation can fail silently and route stays 0.

5. IQ preconditions (AEC/AWB/stats)

• Error 190 when enabling AEC/AWB strongly suggests stats or preconditions not met (e.g., histogram/RGB stats block disabled, invalid ROI, unsupported input for AWB, or missing sensor control bridge for AEC I²C feedback).
• Some stacks validate IQ blocks at init: if statistics cannot be produced/consumed, they refuse init (190) or skip activation later to keep the pipeline consistent.

---

:magnifying_glass_tilted_left: Focus on your register set

• P1DMCR = 0x64420001 indicates demosaic is configured (bits set) but that alone isn’t proof of route activation.
• P1CCCR = 0x00000000 → If color correction / color conversion is off, the ISP might judge the path not viable for RGB565. A typical route for RAW→RGB565 is:
  • RAW10 → Demosaic → Color conversion (RGB) → PixelPacker RGB565
  • If RGB isn’t produced, packer may keep seeing RAW.
• P1SRCR = 0x00000000 is the smoking gun: no ISP‑to‑Pipe1 route.

Hypothesis: The ISP graph misses a mandatory color stage (CCM/CSC) or writer compat, so the activation guard never flips P1SRCR. Error 190 when enabling AEC/AWB reinforces the idea that stats or color domain are not valid.

---

:white_heavy_check_mark: Minimal experiments to isolate quickly

1. Force a bare‑minimum “valid RGB path”

   • Enable Demosaic + Color Conversion (CCM/CSC) to produce RGB888 in ISP.
   • Route ISP output to a simple memory writer sink (if available in your BSP), not just to the pixel packer.
   • Then enable Pipe1 reading from that ISP output.
   • If P1SRCR now flips to non‑zero → the issue is the original graph/sink (PixelPacker) configuration.

2. Switch PixelPacker to a known good RGB input

   • Temporarily configure PixelPacker input to RGB888 from ISP (not RAW).
   • Set packer to convert RGB888 → RGB565.
   • If diagonal artifacts disappear, your earlier path was indeed RAW → RGB misinterpretation.

3. Lower resolution & FPS

   • Try 640×480 @ 15fps RAW10 to reduce bandwidth.
   • If route activates, your original resolution may be choking the clock/AXI path.

4. Enable stats but disable AEC/AWB computations

   • Enable AWB/AEC statistics blocks and confirm they produce non‑zero data per frame.
   • Keep AEC/AWB algo disabled to avoid 190, but prove stats are valid.
   • If stats stay zero/invalid → AWB/AEC will error by design; fix the stats path first.

5. Check CSI‑2 DT/VC explicitly

   • Ensure DT = RAW10 (often 0x2B) and VC matches the ISP input node.
   • Read CSI/DCMIPP frame/line counters and error flags (SOT, CRC, ECC, FIFO) — must be clean.

---

:hammer_and_wrench: Suggested configuration checklist (RAW10 → RGB565 via ISP)

• Clocks / Power

  • ISP/DCMIPP clocks enabled; ISP clock ≥ minimum spec for your resolution.
  • Power domains for camera and ISP on; no LP gating.

• Input

  • CSI‑2: lanes, DT=RAW10, VC consistent with ISP input node.
  • DCMIPP input configured to forward RAW10 to ISP input, not directly to Pipe1.

• ISP graph

  • Demosaic: enabled with RAW10 Bayer pattern matching sensor (e.g., RGGB/GRBG/etc.).
  • Color stage: enable CCM/CSC to produce RGB888 (or YUV if your packer expects it).
  • Gamma / LSC: optional; start simple.
  • Sink: either ISP memory writer or explicit handoff to Pipe1 that expects RGB.
  • Confirm a valid graph (no holes); every enabled block has a connected downstream.

• PixelPacker

  • Input: RGB888 from ISP (not RAW).
  • Output: RGB565, configured for LTDC pixel format and stride.
  • Buffers: aligned; cache maintenance if D‑cache enabled.

• Stats / IQ (for future AEC/AWB)

  • Enable stats blocks (histogram / RGB stats) and verify frame‑by‑frame updates.
  • Configure ROI to full frame while testing.
  • Prepare sensor control bridge (I²C) for AEC feedback (exposure/gain writes).

• Security

  • Ensure ISP → Pipe1 → memory/LTDC paths are within the same (non‑secure or secure) domain with write permissions.

---

:input_numbers: About error 190 (AEC/AWB)

Without the exact middleware mapping, treat 190 as “precondition not met / invalid state”. Typical triggers:

• Stats block not enabled / not routed → no valid data for AWB/AEC.
• Unsupported input: AWB requires Bayer or RGB domain, not YUV or RAW fed to packer directly.
• ROI out of bounds or zero area → invalid stats.
• No sensor feedback path for AEC (I²C writes failing/not configured).

Action:

1. Enable and verify stats first (non‑zero histogram/means).
2. Confirm the ISP produces RGB (not RAW) before activating AWB.
3. Configure sensor I²C bridge for AEC; ensure writes succeed.

---

:clipboard: What to capture to speed up diagnosis

Please add a short dump that includes:

1. CSI/DCMIPP

   • Lanes, DT, VC, frame/line counters.
   • Error flags (SOT, CRC, ECC, FIFO).

2. ISP

   • P1SRCR, P1DMCR, P1CCCR, P1GMCR before and after ISP_Start().
   • Any route activation status flag provided by the BSP.
   • Underflow/overflow counters if available.

3. PixelPacker/LTDC

   • Packer input selection (RAW vs RGB) and output format.
   • Framebuffer addresses/stride; D‑cache ops performed.

4. Stats/AWB/AEC

   • Stats enable flags.
   • Per‑frame stats validity (non‑zero).
   • Exact error stack around 190 (module returning it, function name).

5. Clocks/AXI

   • ISP clock frequency; bus clocks.
   • AXI QoS for camera/ISP masters.

6. Security

   • Attribution of ISP/Pipe1/LTDC and memory regions (secure vs non‑secure).

Regards,

Simon