Solved

Hi, I face the problem with the touchgfx frame rate render has drop periodic after 1000ms that make the animation image (wait circle) has choppiness.My project run on custom STM32U5 has 3MB RAM and 4MB FLASH (I don’t use the external memory). The LTDC configuration at 60Hz(24.5Mhz) for screen 800x480 resolution. The signal when screen not update(full)The signal when screen not update(full)The signal when screen not update(zoom in to see the VSYNC signal)The signal when screen not update(zoom in to see the VSYNC signal) The signal when screen animation the imageThe signal when screen animation the imageThe VSYNC signal is perfect at all.You can run the LogicSystemTimingAnalysis.html in .zip then load the .csv file to see the signal. Thanks,Phat 

 Hello,I have inherited some code where a 5kHz 50% PWM is output in center aligned mode using TIM1. CK_PSC is 275MHz, CK_CNT is 137.5MHz (I think) because PSC = 1.The pattern output matches the implementation:  The yellow trace is a GPIO pin that is toggled in the ISR HAL_TIM_PeriodElapsedCallback(). I want to to keep the same 50% duty but half the frequency to 2.5kHz using the prescaler.From the TRM, it seems I just have to modify PSC from 1 to 2. However, when I do this by poking the SFR register using the debugger, I get the following output:  As you can see, the PWM ratio changes but the frequency does not. I’m at a loss to understand why. So would be grateful for any suggestions.Thank you. In case it helps, here’s my register dump. I have no idea what DMAR is that is my next step.  

..

I am currently using the NUCLEO-H7S3L8 CN2 Type-C port as a USB_OTG_HS embedded PHY host/source.The TCPP03 source path opens successfully, and both the USB stick attachment and port reset are working. After the reset, HPRT reads 0x00001005, which seems to indicate speed=HS and that the port is enabled.However, during the first EP0 SETUP GET_DESCRIPTOR request: HAL_HCD_HC_SubmitRequest() = HAL_OK HAINT = 0x00000001 HCINT = 0x00000080 TXERR = 1 xfer_count = 0 The exact same issue occurs even during a raw HAL EP0 smoke test, prior to involving USBX/FileX.I would like to verify the following points: What is the mandatory clock/power initialization sequence when using the USB_OTG_HS embedded PHY host on the H7S3L8? Is it acceptable to use HSI → PLL3Q for the USBPHYC clock, or is an HSE strictly required? What are the necessary settle/wait conditions after enabling USBHSREG? Are there any required CC/UCPD configurations for the CN2 Type-C/TCPP03 source setup, apart from the PM9

I am working on a project to drive a door using a PMSM motor in position control mode. I am trying to add an emergency brake function. In an emergency, when the operator pushes a button, motor should brake and then return to its starting position without harming anyone.I know there is PWMC_TurnOnLowSides() function (https://community.st.com/t5/stm32-mcus-motor-control/how-can-i-stop-the-motor-urgently/m-p/597309#M8287 ). But it is just stopping the motor, not braking. I have tried this function.As far as I know, there is no such API in position control mode.If I am wrong, is there an API to brake the motor in an emergency? Can anyone help me? Do you have any advice for me?Any information you provide will be welcomed.   Project:ST MCW Ver             : 6.3.2STM32CubeIDE Ver : 1.18.1Driving algorithm      : FOCControl board            : Nucleo-G474REPower board        &

0x0BF97000 (system bootloader base per AN2606): the jump appears to succeed (In Debug reaches the bootloader region), but execution then breaks at an address inside the bootloader ROM with no further progress and no USB enumeration. The hardware boot path works correctly. The problem is purely on the software-jump path.I created an empty project in sample you can download and test it. I also attached my option bytes (i think everything is default).MCU: STM32H573 (also tested h523)/** ****************************************************************************** * @file dfu_jump.c * @author Uğur Tümer * @brief See dfu_jump.h. Implements the magic-word + soft-reset path into * the STM32H523 system bootloader (USB DFU on PA11/PA12). ****************************************************************************** */ #include "dfu_jump.h" /** Magic word stored in TAMP_BKP0R between the request and the next boot. */ #define DFU_JUMP_MAGIC 0xDEADB007UL #define BOOT

Hello,Has anyone seen ACTCLF permanently stuck at 0 on STM32N6 despite a confirmed HS clock at the input?I have had issues with this for some time and need a little help. Pehraps the following questions could be enligtning.Are there SNPS D-PHY initialization or calibration steps for the clock lane beyond what HAL_DCMIPP_CSI_SetConfig performs? Clock-lane equivalents of the 0xe2–0xe4 DDL registers? Can ST confirm the CSI kernel clock (IC18) is the D-PHY cfg_clk, and its required range? The CCFR encoding caps at ~33 MHz and the DK example uses 20 MHz, but we couldn't find this constraint stated in RM0486. Is PTSR being permanently 0 expected on this silicon? Is there any way to verify test-interface writes landed? What exactly are the conditions for ACTCLF to assert? Does the RX require observing a complete LP-11 to LP-01 to LP-00 entry sequence after PEN, and is there a known failure mode if the LP levels at the pad are degraded (e.g., loaded by an external common-mode filter) while HS

Hello,(ST-LINK + CubeProgrammer UART/USB both failing)I am using a NUCLEO-N657X0-Q board. I cannot flashing my code via the ST-Link ( ST-Link windows driver is installed and detected through device manager and I had already updated the stlink). it throws this error:STMicroelectronics ST-LINK GDB server. Version 7.11.0Copyright (c) 2025, STMicroelectronics. All rights reserved. Starting server with the following options:Persistent Mode : DisabledLogging Level : 1Listen Port Number : 61234Status Refresh Delay : 15sVerbose Mode : DisabledSWD Debug : EnabledInitWhile : Enabled Target unknown error 32 Error in initializing ST-LINK device.Reason: Unknown. Please check power and cabling to target.Then tried with CubeProgrammer to connect via STlink but it connects then quickly drops , here is the log :17:22:24 : STM32CubeProgrammer API v2.20.0 | Windows-64Bits17:22:39 : UR connection mode is defined with the HWrst reset mode17:22:40 : UR connection mode is defined with the HWrs

in debugging mode the values of variables gets corrupted when I check in live expressions. Here corrupted means shows wrong values.

When I compile my code, I get strange errors that make no sense.#define ADC_BUFFER 1000 gives error "expected declaration specifiers or '...' before numeric constant"even though the line above it #define ADC_HIGH_THRESHOLD 3500 doesn't generate an error.HAL_TIM_Base_Start(&htim3); and HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_buffer, ADC_BUFFER); both generate "Syntax error".The TIM and ADC Start errors expanded error message is:  error: expected declaration specifiers or '...' before '&' token /* USER CODE END Header *//* Includes ------------------------------------------------------------------*/#include "main.h"/* Private includes ----------------------------------------------------------*//* USER CODE BEGIN Includes */#include <stdlib.h>#include <stdio.h>#include <stdbool.h>#include <stdint.h>#include <inttypes.h>#include "globals.h"/* USER CODE END Includes *//* Private typedef -----------------------------------------------------------*//

Downloaded the update of STM32CubeMX 6.17.0 to install the ARM version on my M4 MacBook Air with macOS Tahoe.  The issue is that it installs an Intel version and not an ARM version.  I uninstalled version 6.16 before installing this updated version.The installer file was SetupSTM32CubeMX-6.17.0-Mac-ARM.app.tar downloaded from the STM32CubeMX download page.The next macOS version after Tahoe will not support Intel apps and was expecting an Apple Silicon version as per the download!What is up with this?

Hello,while testing 6 types of SPI NAND with MP257, I found no 1V8 part boots (tested 2, MT29F4G01ABB and AS5F18G04SND). While looking at scope traces, 32MHz clock from BootROM is almost sinusoidal.I tested booting from Engineering mode and custom BL, it boots Linux as 21MHz but not at 32MHz. IOSPEED is set to “2” (tested 3 too).Then I set bit 14 in OTP 124 (allow for <2.5V for VDDIO3) and then set PWR->CR1 VDDIO3VRSEL too. Now, it boots with 32MHz from my BL (with IOSPEED 2) and clock now seems much nicer.But BootROM seems to ignore OTP 124 and tries to use 32MHz with 1V8 and GPIO in degraded mode.Is there way to make 1V8 OSPI boot work ? Force ROM to either use slower clock or to set VDDIO3VRSEL.Thanks, Martin

From my understanding all STM32N6 chips need a external flash chip and there's a static stage 0 boot loader.  So if this is true is there any limitation's on the brands of flash or speed/address bit size limitations? With the previous stage 0 bootloader for a different non ST product had a lot of limitation on the flash that could be used.* 16 bit flash address only* Only support a few brands of flash chips.  

I’m seeing that the X-CUBE-FREERTOS packege is being updated to 1.6.0 to support FreeRTOS 11.2From the changelog it says that it’s restricted to    - Restricted to processor vendor: STMicroelectronics:13    - Restricted to processor name matching: STM32H5*|STM32U5*|STM32C0*|STM32WBA*|STM32U0*|STM32N6*|STM32U3*Are there any plans to bring to STM32H7* as well?

I have the latest version of STM32CubeIDE for Mac with an Apple Silicon (2.1.1).From time to time, I get the messageWhen I check the program informations, it confirms that I have the correct version (Apple Silicon).I think the problem is caused by Eclipse (version 4.33), which is out of date.Is there an upcoming update for STM32CubeIDE with the ARM version of Eclipse? 

Hi,I am using an STM32U585 MCU in a Iot Application . I am facing an issue during power-up.Problem description: When the main supply is turned ON, the MCU appears to hang or gets stuck somewhere during startup. If I press the reset pushbutton connected to NRST, the MCU starts working normally. After that, the system runs without any issues. Every time I turn the main supply OFF and ON again, the same problem occurs. A manual reset is required for proper operation. This behavior is observed with different power supplies as well. Hardware details: MCU: STM32U585 NRST pin: 10k  pull-up or 100nf capacitor connected Pushbutton reset available on NRST   Any suggestions or recommended checks would be greatly appreciated.Thank you.

Hi everyone,I am encountering an issue where my MCU freezes during continuous data transmission, and I am looking for some advice or debugging directions.Hardware & Setup: MCU: STM32U575 Network Module: ST67W611M1 Protocol: TCP Driver/Firmware Version: V1.3.0 Issue Description: My application is designed to send a 1KB data packet to a remote server every 3 seconds. The transmission works perfectly fine at the beginning. However, after successfully transmitting several hundred KBs in total, the MCU gets stuck.Through debugging, I found that the firmware completely hangs inside the W61_Net_SendData() API.Observations: The remote server is confirmed to be alive and functioning normally when the hang occurs. The MCU does not hard fault; it simply blocks indefinitely inside W61_Net_SendData(). My Questions: Are there any known issues regarding buffer overflows or memory leaks in this specific API when sending large amounts of data over time? Is there a way to configure a non-b

Hi.I’m working with a Nucleo H7A3ZI-Q. It used to work fine, but one day after we did some measurements it suddenly stopped refused to download code. I’m now trying to troubleshoot it. When connected to STM32cubeprogrammer, the board is detected well, but it does not connect, and gives me this error: and this error in the fail.txt: The interface firmware FAILED to reset/halt the target MCU I am also able to update the card with STLink Updater through STLink-V3, which I have done succesfully, but the result remains the same. I have tried on a mac and a windows.

Hi, I’m trying to identify the part number of a STMicroelectronics LDO that is on one of our boards to verify it is the correct part through the device marking. I saw on another forum post that the device marking decoding information is something that only STMicroelectronics has access to internally. Could I please get help identifying the part circled in red by it device marking? It looks like it say 8L533. The part is supposed to be L78L15ABUTR. Thank you,John Sharp Screenshot 2026-06-17 144356.png

Could you tell me VL53L8CX FDA Accession Number?

I have an EtherCAT project that uses the open-source software EtherCAT master station IGH.Currently, my platform is the main controller STM32MP257, and the relative jitter of IGH--enable-generic is relatively large.I would like to inquire if ST has provided corresponding real-time network card driver patches for the EtherCAT master station IGH?If there are any other better solutions, please let me know. Thank you~

Hello, I am trying to setup TIM5 channel 1 to output a signal on its output pin. I generated the code using STM32CubeMX2. I am getting an assert failed during initialization.mx_system_init() calls mx_tim5_init() which calls HAL_TIM_OC_SetConfigChannel(): oc_config.polarity = HAL_TIM_OC_HIGH; oc_config.idle_state = HAL_TIM_OC_IDLE_STATE_RESET; if (HAL_TIM_OC_SetConfigChannel(&hTIM5, HAL_TIM_CHANNEL_1, &oc_config) != HAL_OK) { return NULL; } In HAL_TIM_OC_SetConfigChannel function assert fails at the following line: ASSERT_DBG_PARAM(IS_TIM_OC_OVERRIDE_STATE(p_config->override_state)); ASSERT_DBG_PARAM(IS_TIM_OC_BREAK_MODE(p_config->break_mode));The value of the override_state shown by the debugger  is: (HAL_TIM_OC_OVERRIDE_SET | unknown: 0xfa). If I comment out the assert it will assert on the next line (break_mode). If I comment that line out as well the code outputs a signal on the pin. I attached my MX2 file. What am I missing?-Gil 

Hi everyone, I have successfully set up a camera and the NPU working together on a Nucleo N6 to get proper outputs from the latter, which is great. I also have a way to see the image and can verify the outputs live.However, that only works when I launch the firmware by adding the Application to the startup, loading its symbols, flashing the trusted application and starting to debug the FSBL… After that starts, I can detach the debugger to let it run the application. (BOOT0 off, BOOT1 on)When I now flash both trusted binaries and launch without the debugger (BOOT0 and BOOT1 off) it starts normally and I see the live image. But there are no inference results (which takes the same amount of time as when it worked)… What could I be missing?Best regards, rphii

Hello,I am facing an issue with the STM32C5 HAL SPI driver related to CRC error detection.In my setup, CRC is enabled for SPI. When a CRC error occurs, I can observe that the CRCERR flag is set before the transfer is closed. However, the CRC error is never reported via the HAL error callback.Looking into the HAL implementation, I noticed the following behavior:SPI_CloseTransfer() calls LL_SPI_Disable()After disabling SPI, SPI_CloseTransfer() checks LL_SPI_IsActiveFlag_CRCERR()When this check is performed after LL_SPI_Disable(), the CRC error is no longer detectedIf I move the LL_SPI_IsActiveFlag_CRCERR() check before LL_SPI_Disable(), the CRC error is detected correctlyAdditionally, in my case SPI_CloseTransfer() is called from HAL_SPI_IRQHandler(), but:the return value of SPI_CloseTransfer() is not evaluatedonly the Tx/Rx complete callback is invokedmy error callback is never called, even though a CRC error has occurredFrom my understanding:LL_SPI_Disable() itself does not clear the C

In CubeMX2 when configuring the I2S peripheral on an STM32C542 running from a clock of 144MHz and selecting an audio clock rate of 96000Hz, CubeMX2 computes a nearest reachable frequency of 97826Hz (I2SDIV = 23, ODD = 0). When code is generated and run on actual hardware, the HAL2 I2S driver computes a different value of 95744Hz (I2SDIV = 23, ODD = 1). The HAL2 hardware value has less error from the desired 96000Hz than the value reported by CubeMX2, but the CubeMX2 value may be used in designing other aspects of the firmware and result in unexpected performance.