STM32 MPUs

I'm using a custom board, and use  the optee device tree generated by STM32CUBEMX and full UART log. Panic at core/kernel/dt_driver.c:904 <probe_dt_drivers>. How to solve this problem?

Hi ST,We have developed a custom board based on the STM32MP257F-DK design, with the primary difference being the use of the STM32MP255DAK3 processor in place of the STM32MP257F. All other components and configurations—such as RAM, eMMC, and SD card interface—remain the same as the original DK board.We generated the device tree source (DTS) using STM32CubeMX; however, we are currently unable to boot the board successfully. Initially, we encountered an error related to the RISAF component, which we managed to resolve. Unfortunately, we are now facing a new issue resulting in a Panic in EL3 error.Despite our efforts, we have not been able to determine the exact root cause of the problem. Given that only the processor has changed and all other hardware remains identical, we would appreciate any guidance or suggestions you could provide to help us resolve this issue and complete the bring-up process.NOTE:  the 1st error ################################################NOTICE: CPU: STM32

Hello ST Community, We are developing a product based on STM32MP151 which has 2 (WKUP) GPIOs connected to wake our battery-powered product from sleep or shutdown. Can somebody please let us know how we can detect which GPIO triggered the wakeup in linux userspace? We have to execute specific functions in our C application based on which GPIO triggered wakeup of our STM32MP151 based product. We are using latest openstlinux distribution package and we are open to creating a kernel module if that's required, but need some basic guidance on where to look at. Please note: We also use "rtcwake" to wakeup our product at regular intervals. Our product needs both GPIO and RTC wakeup sources. Best Regards,Ayush Sharma

Dear Sir/Madam, We are currently using CubeMX version 6.1.4 alongside CubeIDE version 1.18.1 to generate code for the M33 microcontroller. However, we have encountered an issue where the clock configuration functions are not being generated as part of the code.We kindly request your guidance on resolving this matter. Please let us know if further details are required.Thank you for your assistance.Best regards

Hi,I'm trying to understand what the viable options are.my goal is to be on more recent versions of kernel/uboot because there are features upstream that I need.my preference is to be following upstream.Current situation is that i'm using stm32s fork of Linux that is resting on 6.6.x, and equivalent uboot. I see a lot of upstream activity from STM32 FOSS team, with lots of progress in linux 6.17 and 6.18. I also note that at least somethings are not upstream, such as hsem in stm32mp151.dtsi. and easy thing for me to patch on it's own, but i'm looking at the bigger picture and the unknowns of what else might not be upstream that I don't know I need etc.I'm aware that I can sift through the mailing lists and find all the upstream requests where i'm certain i could eventually curate a more complete 6.17/6.18 with respect to the MP1. I also imagine the FOSS team have this already?is there a set of patches for complete MP1 support (as i assume the stm32 linux fork is complete) that can

Hello everyone,I am reaching out to the community regarding an issue my team is experiencing on the STM32MP257F, specifically within a project running on the Cortex-M33 core.ContextWe are attempting to configure SPI2 to transmit data to an external DAC using HPDMA1. While SPI2 transmission works correctly without DMA, integrating HPDMA results in no data movement—DMA does not appear to start, and SPI output remains idle.We initially relied on CubeMX for code generation, but due to several inconsistencies (e.g., peripherals marked as enabled were not properly configured, some register settings missing), we shifted to a manual initialization approach. Unfortunately, the issue persists.Technical RequirementsThe intended configuration is as follows:DMA Mode: Standard transfer (no linked list).Direction: Transmit only; no receive path required.DMA Request Source: HPDMA_REQUEST_TIM3_UPTIM3 period: 50 µsClock: 200 MHz, Period register: 9999Trigger Source: TIM15_TRGOTIM15 period: 250 µsClock:

I'm facing a problem when trying to build an image for my mp257f-eval board using a custom device tree generated from cubemx. I've followed the instructions from the following wiki : https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Distribution_Package#Creating_a_new_open_embedded_layer_for_your_demo But the build fails when trying to compile optee, because the device tree does contains a reference for a pll device not declared earlier. i did some lookups inside the working directory, and i found it declared in the recipes-security/optee folder under meta-st-stm32mp meta layer (https://github.com/STMicroelectronics/meta-st-stm32mp/blob/scarthgap/recipes-security/optee/optee-os/0001-4.0.0-stm32mp-r2.patch). i guess the patch is not applied to the device tree, only the standard device trees for common boards get patched. i don't know if someone has faced a similar problem and can help? I'll attach the log and configs files using for the build. thanks in advance.T

Hii, I am using STPMIC25A with STM32mp257FAK3 with DDR3L in one custom design and LPDDR4 in second custom design.I am able to change o/p of Buck 4, Buck 6 and LDO 3 as per the requirement by changing the voltage for the same in the device tree, under fdts in Arm Trusted Firmware. I am sharing the node below:&i2c7 {pinctrl-names = "default";pinctrl-0 = <&i2c7_pins_a>;i2c-scl-rising-time-ns = <185>;i2c-scl-falling-time-ns = <20>;clock-frequency = <400000>;status = "okay";#address-cells = <1>;#size-cells = <0>;pmic2: stpmic@33 {compatible = "st,stpmic2";reg = <0x33>;status = "okay";regulators {compatible = "st,stpmic2-regulators";vddcpu: buck1 {regulator-name = "vddcpu";regulator-min-microvolt = <800000>;regulator-max-microvolt = <910000>;regulator-always-on;};vddcore: buck2 {regulator-name = "vddcore";regulator-min-microvolt = <820000>;regulator-max-microvolt = <820000>;regulator-always-on;};vddgpu: buck3 {reg

Hello everyone,I'm experiencing an issue with network packet loss in a setup using the AR8031 PHY with an STM32MP1 system and would appreciate any insights or suggestions.Problem Description:Significant (60-90%) packet loss when STM32MP1 board is directly connected to a Linux host via EthernetNo packet loss when the same board is connected through an Ethernet switchIssue occurs consistently with direct host connectionsTested/Verified so far:Multiple known-good Ethernet cables (CAT5e/CAT6)Different Linux hostsLink speed and duplex settings (100M/1G, full/half duplex), 100M works fine with no packet lossEnable/disable various PHY driver quirks (qca,disable-smarteee, qca,disable-hibernation-mode, qca,clk-out-strength, qca,keep-pll-enabled, qca,smarteee-tw-us-1g)Device Tree Snippet:&ethernet0 { status = "okay"; pinctrl-0 = <&ethernet0_rgmii_pins_a>; pinctrl-1 = <&ethernet0_rgmii_sleep_pins_a>; pinctrl-names = "default", "sleep"; ph

I want to run OpenSTDroid on the STM32MP2 DK board, I cannot wait for ST to add support so what's the bare minimum I can do to run it on the DK board? I don't mind WiFi or Bluetooth not working, I just want to get Android running first, Then I can work on drivers.As I understand I think I can get away with just modifying the DTS overlay file to match the new hardware.

My freshly arrived and assembled STEVAL-ROBKIT works well in Autonomous and Follow-Me mode but not in Drive. Nor does the "lock" toggle seem to do anything.  Lock does not stop Follow-Me if activated.  Any ideas?John FergusonSt Petersburg, FL

I'm working on an STM32 project using STM32CubeIDE with CMake as the build system. I need to add custom include paths for my own header files.I tried to include my_folder from C/C++ General -> Paths and Symbols -> Includes, but it doesn't work.Note that under C/C++ Build -> Settings there is no settings to include anything, which are available only when working with STM32CubeMX/STM32CubeIDE Project   

Hi everyone,I need some guidance on building a real-time face recognition pipeline on the STM32MP2 platform.My requirements:Reliable face detectionGood, consistent face embeddingsDecent FPS on MP2Preferably ONNX or pure CPU, since heavy frameworks aren’t idealMinimal external dependenciesNo reliance on TensorFlow or PyTorchI’m looking for suggestions on:Which face detector works best on MP2 (YUNet / SCRFD / BlazeFace / SSD)?Which embedding model (ArcFace, MobileFaceNet, SFace, etc.) performs well on CPU?Any recommended ONNX + OpenCV DNN pipelines that others have successfully run on MP2?Tips for optimizing inference speed on this hardwareIf anyone has experience or working examples, it would really help me understand the right direction to build a practical, efficient solution.Thanks in advance!

Hi!I am working on a custom board design based on STM32MP157FAA1.I need to interface a MIPI display with the microprocessor.I am powering this microprocessor using STPMIC1APQR PMIC. As per the datasheet of the PMIC, the default output voltage from BUCK3 will be 3.3V and this powers VDD_DSI (Pin A14) and I am also aware that the microprocessor internally generates 1.2V for DSI section.Now the MIPI display I'll be using utilizes EK79007 LCD driver IC. The recommended VDD for EK79007 is 1.8V. I want to know if this display can be interfaced with the MIPI section of STM32MP157FAA1.I have added the data sheet of the display and also the LCD driver for your reference.Thanks & Regards,Cleatus Wesley

Hello,I am attempting to run the OpenAMP_TTY_echo_CM33_NonSecure example following this guide Modify, rebuild and reload the firmware but run into the following error when attempting to run the example.IDE ErrorError in final launch sequence: Failed pre launchFailed pre launchFirmware remoteproc load failed, please:    1. make sure that /lib/firmware on your target has space    2. make sure that /lib/firmware has write access   > you can open a Console View for this..Serial Terminal Logs[   82.376063] remoteproc remoteproc0: powering up m33[   82.378336] remoteproc remoteproc0: Image is corrupted (bad magic)[   82.381610] remoteproc remoteproc0: Boot failed: -22Run configuration I have attempted to use the .elf file as suggested here https://community.st.com/t5/stm32-mpus-software-development/error-using-cubeide-ro-run-an-example-application-for-the/m-p/721825 but get the a similar IDE error with the followin

 I have observed that on the STM32MP25 series running OpenSTLinux, the GPU OpenVX packages are correctly built and the *.so files are present in the rootfs. However, after the do_image step, these libraries are removed and are missing in the resulting ext4 image. Consequently, if I flash the image, the OpenVX shared libraries are absent.Here are the debugging details:The GCNANO_PACKAGECONFIG is correctly set to "egl gbm glesv1 glesv2 vg vx cl vulkan", and this has been verified.Other libraries are installed correctly. For example, in the rootfs:  root@stm32mp25:/vendor/lib# ls libCLC.so libGLESv2.so.2.0.0 libSPIRV_viv.so libvulkan_VSI.so.1.3.3 libEGL.so.1.5.0 libGLSLC.so libVSC.so libGAL.so libOpenCL_VSI.so.3.0.0 libgbm.so.1.0.0 libGLESv1_CM.so.1.1.0 libOpenVG.so.1.1.0 libgbm_viv.so During the build, the OpenVX libraries are correctly generated in the rootfs. For example, I confirmed that libArchModelSw.so exists at:  tmp-glibc/work/stm32mp25x-ostl-linux/s

How can I build the M33TD Yocto images from sources?stm32mp2-m33td-openstlinux-6.6-yocto-scarthgap-mpu-v25.06.11 I managed to build the A35 flavor following this excellent summary:Solved: stm32mp257f-EV1 yocto - STMicroelectronics Community But now I would like to do the same for the M33TD boot mode. My board is a STM32MP257F-EV1

We are using customised board on stm32mp257f microprocessor. We have used STM32MP257F-DK as a reference for the hardware design. In our customized board, we have used  LVDS panel and kept the LVDS section same as that of STM32mp257f-dk board. The board boots up and kernel is loading properly. But lvds panel is not working. Please find below the error logs in u-boot and kernel.Receiving following uboot log:stm32_ltdc_probe: Startedstm32_display display-controller@48010000: stm32_ltdc_probe: LTDC hardware 0x40101stm32-display-dsi dsi@48000000: stm32_ltdc_get_panel(dsi@48000000): no UCLASS_DISPLAY for remote-endpointstm32-display-dsi dsi@48000000: stm32_ltdc_get_panel(dsi@48000000): no UCLASS_DISPLAY for remote-endpointstm32_display display-controller@48010000: Device failed ret=-22stm32_display display-controller@48010000: stm32_ltdc_display_init(display-controller@48010000): no UCLASS_VIDEO_BRIDGE for remote-endpointstm32_display display-controller@48010000: Device failed ret=

Hello,We are working with the STM32MP257F-FK Discovery board and are facing an issue while calculating the signature of a memory region.We are following the recommended sequence for initiating the signature computation. The CRCEOC flag is being set as expected, indicating that the operation has completed. However, the resulting CRC value in the corresponding register remains 0x00 instead of the expected signature.Could you please help us understand why the CRC result is not being populated and advise if there are any additional steps or configuration requirements specific to this device?Below is the exact sequence we followed, as documented:Write 0x0 to CRCC[1:0] in RAMCFG_xCCR1 to deactivate the CRC.Write 1 to SRAMHWERDIS in RAMCFG_xCR to disable hardware erase.Select the buffer size for the CRC computation by configuring CRCBS[2:0] in RAMCFG_xCCR1.Write 0x1 to CRCC[1:0] in RAMCFG_xCCR1 to activate the CRC.Write 1 to CRCCS in RAMCFG_xCCR2 to start the CRC computation.As per the refere

Hello! I've been fighting with the MP13 for a couple months now in trying to enable reading/writing to the NAND, as well as configuring ethernet and keep running into issues with being unable to update the necessary registers for this. When writing to the extended truztone protection registers, no change is made. The clock's enabled, so that shouldn't be it. Within the reference manual, it states "ETZPC registers are write-secure (that is, read accesses are allowed by secure and non-secure domains, write accesses are allowed by the secure domain only". I've yet to figure out how to be in the "secure" domain to update these bits so I can actually use most of the features of this board without using Digi's yocto builds.Any thoughts/advice on the above?

Hello,I have made a custom STM32MP133D board and I am in the process of building the custom bring up. The bringup uses discrete regulators and not a pmic. I have followed the process of building the device tree for the TF-A and build the TF-A .stm32 binary configured for USB. The .stm32 successfully flashes but the code stucks on ASSERT: drivers/st/regulator/regulator_fixed.c:81 and Exception mode=0x00000016 at: 0x00000000 suggesting a null pointer and an underline issue with my dts.I have made the ddr memory tests for the pcb bring up and successfully passes  all the memory  tests using the tfa.dtsi ddr configuration.I have also attached the the device tree for the tfa.Can anyone help me with this issue?// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-3-Clause) /* * Copyright (C) 2025, STMicroelectronics - All Rights Reserved * Author: STM32CubeMX code generation for STMicroelectronics. */ /* For more information on Device Tree configuration, please re

Hi,We're working on a new open source wildlife camera system and planning to use ST's 1.5 Mp and new 5 Mp image sensors with an STM32N6x7 series MCU for routine MIPI CSI-2 camera interface, ISP, h.264 video encoding, storage and possibly CNN (Convolutional Neural Network) inference with a separate STM32MP25x booting embedded Linux when advanced functionality is needed.We were wondering if it would be a practical possibility at all to use an STM32MP25x series MPU with bare metal for routine MIPI CSI-2 camera interface, ISP, video encoding and storage tasks as well as for running embedded Linux or if this would be a theoretical possibility but potentially practically difficult to implement?Moe about ST image sensors:https://www.st.com/en/imaging-and-photonics-solutions/industrial-consumer-cmos-image-sensors.htmland about our conservation work:https://new-homes-for-old-friends.cairnwater.com/quick-summary-new-homes-for-old-friends-belgium/Thank you for your help! / Mer

Hello,We are using an STM32MP151 on a custom board and facing an issue with USB device connection via EHCI (USB 2.0).Problem description:After issuing a PORT_RESET, the J/K chirp sequence does not start, and we get a timeout error.If we disable EHCI and use OHCI, the device connects successfully.Hardware difference compared to evaluation board:Our design does not include a high-speed hub IC.The USB Type-A connector is directly connected to the STM32MP151.Questions:Has anyone experienced similar behavior on a custom board without a high-speed hub?Are there any hardware design requirements (VBUS, RREF resistor, clock quality) or Device Tree settings that need to be adjusted for EHCI operation?Any recommended debug steps for this issue?Additional info:Kernel logs show timeout after PORT_RESET.OHCI works fine for full-speed devices.Any guidance or suggestions would be greatly appreciated.Thank you!

Hi,I was wondering if there's any guidance on the approximate timeline for rebasing OpenSTLinux from kernel 6.6 to kernel 6.12 (autumn 2024) or to kernel 6.15, 6.16, 6.17 or 6.18?I know that this is an enormous amount of work and a very complex task - the STM32MP25 is an extremely advanced chip and there are some significant changes in the kernel between kernel 6.6 and kernel 6.12 LTS and later kernels so it won't be possible to give any definite timescales for this at this stage.It would be great to have a very approximate rough idea of the planned timelines for this since the advances in the kernel between 6.6 and 6.15 LTS make significant improvements in the kernel's ability to handle advanced functionality on the STM32MP25 and on ST image sensors. :)Thank you very much for your help!Will

We ordered an STM32MP257F-DK evaluation board - DigiKey part number "497-STM32MP257F-DK-ND" - on 25 September 2025 and had it delivered to Zürich.On 15 October 2025 we ordered the same ST STM32MP257F-DK evaluation board with DigiKey part number "497-STM32MP257F-DK-ND" for delivery to one of our developers - Paul - working remotely.Paul booted the ST STM32MP257F-DK board using the SD card that was supplied with it and was able to take it into and out of suspend-to-RAM with no problems however when we try to reproduce this with exactly the same steps with the ST STM32MP257F-DK here in Zürich it fails to waken from suspend-to-RAM.We thought that it could be a difference in the images on the ST cards for the two boards so we copied the image for the SD card on the board delivered to Paul and tested it on the board here with exactly the same results.We also checked that the WakeUp switch on the board is electrically functional - when I press it:[ 290.372530] optee: no desc for optee IT:1We