Skip to main content
Associate
July 20, 2026
Question

How to Integrate camera with STM32MP257F-DK and STM32N6570-DK using DCMI

  • July 20, 2026
  • 3 replies
  • 76 views

I am working on camera integration with both the STM32MP257F-DK and STM32N6570-DK development boards and would appreciate some guidance from the community.

My setup

  • Boards:

    • STM32MP257F-DK

    • STM32N6570-DK

  • Camera sensor: Suggest One camera Sensor for both, currently I have VD55G1 and VD66GY

  • Software: ST OpenSTLinux (Yocto) on STM32MP257F-DK

My questions

  1. Is it possible to interface a camera to the STM32MP257F-DK using the DCMI peripheral, or is MIPI CSI-2 the only supported camera interface for this board?

  2. For the STM32N6570-DK, what is the recommended approach for connecting a camera through DCMI?

    • Are there any supported camera modules or reference designs?

    • Are there example projects available for image capture using DCMI?

  3. If the camera sensor provides only MIPI CSI-2 output (such as the VD55G1 and VD66GY), is an external bridge/converter required to use it with DCMI?

  4. Are there any ST application notes, reference designs, or GitHub examples demonstrating camera integration using DCMI on either of these boards?

  5. If anyone has successfully integrated a camera with either STM32MP257F-DK or STM32N6570-DK, I would appreciate any advice regarding:

    • Hardware connections

    • Device Tree configuration (for STM32MP257F-DK)

    • Linux/V4L2 driver configuration

    • STM32CubeMX configuration (for STM32N6570-DK)

    • Example code or sample projects

Any documentation, example projects, or recommendations would be greatly appreciated.

Thank you!

3 replies

mƎALLEm
ST Technical Moderator
July 20, 2026

Hello ​@balasaivura and welcome to the ST community,

I’m posting here as a community admin.

You are asking the same question for totally different platforms: MCU (STM32N6) which a microcontroller and MPU (STM32MP2) which is a microprocessor.

There are two different forums for MCUs and MPUs:

For MCUs:

For MPUs:

So what I suggest is to dedicate one post for each product.

Thank you for your understanding.

To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
Pwxn
ST Employee
July 21, 2026

Hello,

I will reply for the STM32MP257F-DK only. 

On the DK board, we only open the MIPI CSI-2 port, this port is directly tied to the DCMIPP. For more information on the DCMIPP please refer to the Ref man RM0457 - Chapter 49 - Digital camera interface pixel pipeline.

 

Then, with the STM32MP257F-DK and EV board we provide the the B-CAMS-IMX module board that embed a IMX335 camera sensor. So, the DTS, code source of the starter package is dedicated to this module. If you which to test another module on the DK/EV boards you need to adjust this.

 

To modify the camera sensor from the imx335 to another product you need to modify the device tree and provide the correct source code to the kernel. You need to modify the camera definition in the i2c2 node and the csi endpoint as well so both definition are aligned:

 

imx335: imx335@1a { 
compatible = "sony,imx335";
reg = <0x1a>;
clocks = <&clk_ext_camera>; #
avdd-supply = <&imx335_2v9>;
ovdd-supply = <&imx335_1v8>;
dvdd-supply = <&imx335_1v2>;
reset-gpios = <&gpiob 1 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;
powerdown-gpios = <&gpiob 11 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;
status = "okay";
port {
imx335_ep: endpoint {
remote-endpoint = <&csi_sink>;
clock-lanes = <0>;
data-lanes = <1 2>;
link-frequencies = /bits/ 64 <594000000>;
};
};
};

&csi {
vdd-supply = <&scmi_vddcore>;
vdda18-supply = <&scmi_v1v8>;
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csi_sink: endpoint {
remote-endpoint = <&imx335_ep>;
data-lanes = <1 2>;
bus-type = <4>;
};
};
};
};

 

Important points:

  • Use the correct address i2c

  • Compatible: use the correct names

  • Clocks and supply must complied with the camera requirement

  • GPIOs must also be configured according to the needs of the camera (board module and sensor).

 

You must compile the source code of the new camera sensor to use it on the distribution.

Source code of imx335 can be find on the source: linux/drivers/media/i2c/imx335.c at v6.6-stm32mp · STMicroelectronics/linux

How to integrate the new module with the developer Package: How to cross-compile with the Developer Package - stm32mpu

 

I hope this will give you a clear view of what need to be done.

Regards,

Associate
July 24, 2026

Hello @Pwxn,

Thank you for your previous guidance.

I have already updated the Device Tree by replacing the IMX335 with the VD56G3 sensor. I modified both the I2C camera node and the CSI endpoint so that they match, as recommended.

I also built and loaded the VD56G3 kernel driver from the ST repository:
https://github.com/STMicroelectronics/vd56g3-linux-driver

The driver probes successfully during boot:

 
[    9.663234] vd56g3 0-0010: supply vcore not found, using dummy regulator
[ 9.668362] vd56g3 0-0010: supply vddio not found, using dummy regulator
[ 9.675793] vd56g3 0-0010: supply vana not found, using dummy regulator
[ 9.725838] vd56g3 0-0010: Successfully probe vd66gy sensor

However, when I attempt to capture a frame using:

 
v4l2-ctl -d /dev/video0 --stream-mmap=4 --stream-count=1 --verbose

the stream fails to start, and I observe the following kernel messages:

 
dcmipp 48030000.dcmipp: dcmipp_input: format update: old:1120x1360 (0x3002, 3, 0, 0, 0) new:1120x1360 (0x300a, 3, 0, 0, 0)

dcmipp 48030000.dcmipp: dcmipp_main_isp: source format update: new:1120x1360 (0x100a, 3, 0, 0, 0)

dcmipp 48030000.dcmipp: Invalid format given

dcmipp 48030000.dcmipp: dcmipp_bytecap_start_streaming: Failed to start streaming, media pipeline start error (-22)

It appears that the sensor is detected correctly and the media pipeline is configured, but DCMIPP rejects the negotiated pixel format during stream startup.

For reference, I have attached the outputs of the following commands:

  • media-ctl -p
  • v4l2-ctl --list-formats-ext
  • v4l2-ctl --all
  • v4l2-ctl -d /dev/video0 --stream-mmap=4 --stream-count=1 --verbose
  • Relevant kernel (dmesg) logs

Could you please help me understand:

Could you review the attached outputs and indicate whether the media pipeline or pixel format negotiation is incorrect?

Thank you for your support. I appreciate any guidance you can provide.