STM32CubeMX (MCUs)

@Mahmoud Ben Romdhane I am still seeing this on ST Cube MX 6.16.1 when generating for the STM32F723E-DISCO target. This is using the latest STM32F7 package, 1.17.4. Attached is my IOC file if that's helpful.I know its a trivial fix but wanted to report this is ongoing.

The CubeMX suddenly can't generate some .h files such as stm32f103xb.h, core_cm3.h, stm32f1xx_hal_rcc.h ..., I tried to use legacy CubeMX to generate but still the same.How to fix it?Left picture is what it should look like ,and the right one is the wrong one.

Hi,during porting the USBX as host stack to an stm32h7 I was getting an error indication,that a semaphore was used during interrupt context (OTG_HS_IRQHandler).For my opinion, it is wrong to call the generated code out of the ISR without decoupling the context. How did you solve the problem? Is there a posibility in cubemx the generate code with decoupling the context?.

I'm trying to download Cube MX, Cube Programmer, and Cube IDE. I registered and activated the license, but it won't download. I've tried using different browsers (Chrome, Firefox, Edge) without extensions. I accept the License Agreement, but nothing happens. I tried it as a guest user, too, but it won't download. I really need the programs, what should I do?

Im trying to setup FreeRTOS with the new STM32N6.According to https://github.com/STMicroelectronics/x-cube-freertos, the new Nucleo board for the STM32N6 is mentioned as supported.But in the CubeIDE, when trying to enable the FreeRTOS middleware, it says that the new nucleo board is not supported. And the docs also only mention AzureRTOS as supported.Is FreeRTOS supported through the CubeIDE? Or only AzureRTOS? 

Hello,I found a CubeMX database issue affecting STM32H747 dual-core projects using FreeRTOS with CMSIS-RTOS V2.EnvironmentMCU: STM32H747Cube/HAL: STM32CubeH7 1.13.xCubeMX: 6.17FreeRTOS: 10.6.2ProblemTwo FreeRTOS configuration parameters are not present in the MicroXplorer Configuration settings and are not retained in the internal IOC model:configUSE_SB_COMPLETED_CALLBACK configUSE_MINI_LIST_ITEMBecause of that, code generation can produce invalid output in FreeRTOSConfig.h such as:#define configUSE_MINI_LIST_ITEM ( valueNotSetted ) #define configUSE_SB_COMPLETED_CALLBACK ( valueNotSetted )This breaks the build and/or downstream FreeRTOS code.Editing the .ioc manually does not solve it permanently, because CubeMX overwrites the .ioc on regeneration.Adding manual defines in USER CODE blocks is only a local workaround and does not fix the root cause.Root cause foundThe issue appears to be in the CubeMX FreeRTOS mode database, not in the generated project itself.For STM32H747, CubeMX uses

I am using a G474RE nucleo board and i have 2 separate interface boards which i ca connect to it. One board requires a VREFBUS of 2.5V and the other  2.90 . Currently i modify the .IOC file and select the appropriate VREFBUS, compile the code. So currently i have 2 separate .elf files, one for each scenario. I will want a single code version so that on start up based on the status of a switch connected to a GPIO, it will configure the correct VREFBUF value. The attachment shows my setup for the 2.90V internal voltage reference. Thanks David  

  I don't use this Tx Buffers Nbr. Instead, I use this Tx Fifo Queue Elmts Nbr for sending. The difference between the two is just that one is manually sent and the other is sent by hardware, right? Why does the software give me a pink prompt for Tx Buffers Nbr, stating that the number of Tx Buffers Nbr plus the number of Tx Fifo Queue Elmts Nbr must be 32? What does this mean? Help me, I'm about to cry.I don't use this Tx Buffers Nbr. Instead, I use this Tx Fifo Queue Elmts Nbr for sending. The difference between the two is just that one is manually sent and the other is sent by hardware. Why does the software give me a pink prompt for Tx Buffers Nbr? The number of Tx Buffers Nbr plus the number of Tx Fifo Queue Elmts Nbr must be 32. What does this mean? Help me, I'm about to cry. God!

I upgraded to 6.17 this morning an have already had to roll back due to a bug in how it now generates fiels for FreeRTOS.Under the FreeRTOS (Include parameters) options I have this vTaskDelayUntil set to Enabled.  This now changes the define name in the user config file (Core/Inc/FreeRTOSConfig.h) to be #define INCLUDE_xTaskDelayUntil 1which is correct for the updated freeRTOS version, but in the file (Middleware/Thrid Party/FreeRTOS/Source/CMSIS_RTOS_V2/freertos_os2.h) it has not been updated so it now it throws an error stopping my projects from building. There are other places where vTaskDelayUntil has also not been updated to xTaskDelayUntil. This needs to be fixed.  

Hello, I got following problem.STM32CubeMX is unable to properly generate .project file for STM32CubeIDE. After clicking "GENERATE CODE", MX is copying library files, generating .h and .c files, but no .project file. Following nullpointer exception can be found in log file. I already tested different versions of JAVA - no change. I attached error messages, MX log, and .ioc file. Anyone managed to fix this?  2026-03-15 10:27:00,707 [ERROR] ToolchainGenerator:531 - java.lang.reflect.InvocationTargetException: null at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:115) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:580) ~[?:?] at com.st.microxplorer.plugins.projectmanager.model.ToolchainGenerator.CallMethod(ToolchainGenerator.java:406) ~[?:?] at com.st.microxplorer.plugins.projectmanager.model.ToolchainGenerator.generate(ToolchainGenerator.java:506) ~[?:?] at com.st.microxplorer.plugins.projectmanager.engine.Pro

Hi ST,I have a STM32H7 project with FW_H7_v1.12.1 and MX v6.16.1, everything is good so far.But after migration to FW_H7_v1.13.0, I can't generate FreeRTOS code any longer.All FreeRTOS-related code are deleted and MX stay loading icon when I click FREERTOS component.I tried uninstall MX and then install latest MX v6.17, but the same.I also tried install X-CUBE-FREERTOS component, but still the same.Please find my ioc file as attachment.Is there anything I can do?Thank you very much.BRs,-Engin

Split from Inconsistent pin naming - this is a separate suggestion.I would like the option to have the define of a particular GPIO port, or all defines, not typecasted to a pointer. So only the base address as an uint32_t (or uintptr_t). This would make using it in C++ in constexpr easier. Because reinterpret_cast and pointer comparison is not allowed in a constant expression. This should be an additional define for backwards compatibility.  #define CLK_A_GPIO_PIN GPIO_PIN_0 #define CLK_A_GPIO_PORT GPIOF #define CLK_A_GPIO_PORT_BASE GPIOF_BASE // <- for use in constexpr In C++ it would be much easier to do things at compile time using templates and constexpr this way. Example:you want to create a function at compile time that sets 2 defined pins highif they are the same port they can be combined in one call to GPIO_set()if they are not the same port they need to be separate callsno macros needed in user code, no runtime checks needed, no manual tweaks n

Hi there,I've been using the STM32H7R7 device (BGA225), but I ran into an issue. I used the TochGFX (4.26) to generate the gfx_task, and after that, I configured the cubemx (6.17), but somehow the linker was not good. Even my code could not be built since the external PSRAM was not set up automatically. I fixed it, but I ran out of ideas. I would highly appreciate it if the demo were to be available to move forward. Thank you very much!Geri

I am using an STM32H7 MCU and configuring the system clock to 400 MHz using CubeMX. The clock tree shows SYSCLK = 400 MHz, and MCO2 is configured to output SYSCLK.However, when I debug:HAL_RCC_GetSysClockFreq() returns 64 MHzRCC->CFGR shows SWS = 0 (HSI is used)SW = 0, meaning the system is not switching to PLL It seems that the PLL is not being selected or is failing to lock, and the system remains on HSI. I have configured PLL and SYSCLK source in CubeMX, but the change is not reflected at runtime.HAL_RCC_GetSysClockFreq() RETURNS 64MHZ  

Hello,I found a bug in STM32CubeMX code generation for STM32H7S3.When configuring Ethernet with external clock input (ETH_CLK pin,PD6 with AF4_ETH) as PHY clock source, CubeMX does not generateGPIO initialization for this pin in HAL_ETH_MspInit().Workaround - must add manually:__HAL_RCC_GPIOD_CLK_ENABLE();GPIO_InitStruct.Pin = GPIO_PIN_6;GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;GPIO_InitStruct.Pull = GPIO_NOPULL;GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;GPIO_InitStruct.Alternate = GPIO_AF4_ETH;HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);Without this, Ethernet does not work even though all otherETH pins are correctly initialized by CubeMX.Steps to reproduce:1. Select STM32H7S32. Enable Ethernet (ETH)3. Set clock source to external clock via ETH_CLK pin (PD6)4. Generate code5. ETH_CLK pin GPIO init is missing in generated codeCubeMX version: 6.17.0MCU: STM32H7S3Thank you

Please use English on this forum.Translated: The development board is STM32H723, using stm32cubemx for development, debug is disabled, using stlink to burn found that it can be burned, and it can also be debugged, which is very strange! (The development board is STM32H723.) It was developed using STM32CUBEMX. The debugging option is set to "Disabled". Programming with stlink, discovering that it can be programmed and debugged. It's weird! ）Original:开发板为STM32H723，使用stm32cubemx进行开发，debug勾选禁用，使用stlink烧录发现可以烧录，并且还可以调试，非常奇怪！（开发板是STM32H723。它是使用stm32cubemx开发的。调试选项设置为“禁用”。使用stlink进行编程，发现可以编程，也可以调试。这很奇怪！） 

Hi,I am using the STMH745 MCU and trying to synchronize the ADC trigger to HRTIM. For HRTIM I set the "ADC Trigger Configuration" as given in figure HRTIM.jpg - it defines only a SINGLE trigger. However, in ADC configuration (figure ADC.jpg), TWO HRTIM trigger outs are visible.Can anyone explain the relation between these two option sets? How to correctly synchronize the ADC trigger to the given value value of a HRTIM timer?Thanks!

Hi everyone,I just started developing software for a new project containing on of the STM32L4P5 series microcontrollers. Therefore I bought the NUCELO-L4P5ZG starter-kit to get used to the IDE, HAL and so on. I use the STM32CubeMX IDE (Version 6.16.1) to configure the board and generate the basic initialization sources. Further code writing is done in STM32CubeIDE (Version: 2.1.1).For the beginning I configured three GPIO pins for the LEDs on the board and the LPUART for simple data transfer to terminal on host computer. For the transmission I want to use DMA . After generating the code with CubeMX and implementing some simple blink logic for the LEDs, I added the line HAL_UART_Transmit_DMA(&hlpuart1, buffer, 14); to the main loop. I debugged the code and saw that the code ran into the infinite loop in the DefaultHandler in the startup file startup_stm32l4p5zgtx.s: After searching for two and a half hour I finally found the problem: the generated names for the interrupt h

Hi. I want to use the A HRTIM timer to independently control two MOSFETs. Namely, I have a transformer with the midpoint connected to the positive pole of the power supply, and these two transistors switch the 2 halves of the winding as lower switches to generate 2 half-waves of a sine wave.But I can't configure it in STN32CubeMX for the second output the condition for set. STN32CubeMX "Set Sources: nothing to set as Dead Time is enabled, Output2 signal is defined based on Output1 Configuration Set Sources must be 0." although the channels are configured as independent. Moreover, before the update there was no such problem. Now STM32CubeF3 Firmware Package V1.11.5Why the problem? 

I've always found it a little irritating:#define CLK_A_Pin GPIO_PIN_0 #define CLK_A_GPIO_Port GPIOFWhy is it deemed necessary to have "GPIO" in one, but not the other? Surely, that should be either:#define CLK_A_GPIO_Pin GPIO_PIN_0 #define CLK_A_GPIO_Port GPIOF("GPIO" in both), Or:#define CLK_A_Pin GPIO_PIN_0 #define CLK_A_Port GPIOF ("GPIO" in neither) (There isn't a label for "suggestion" - so "bug report" is the nearest option)

Hello, I am using the STM32H503 MCU. When I configure the pins as follows:PB2 → OUTPUTPA8 → TIM1_CH1PB7 → I2C1_SDAIn the RCC section, I get red warnings for Master Clock Output1 (MCO), LSCO clock output, and SAI1 External clock. I cannot disable these clock settings. Is there a way to do this in CubeMX? How can I resolve this conflict in CubeMX?

I am using STM32CubeMX (Version 6.17.0). Here is what happened. I created a PIN name "CLK-A". After some troubleshooting, I found a mistake in my pinout definitions. I named the correct pin as "CLK_A". However, I did not delete the "CLK-A" pin. When the C code was generated for the project, the "CLK-A" pin was defined as "CLK_A" in the output C file. The tool did not flag me that there were two pins with the same effective name. It took me some time to track down the issue. Once I deleted original "CLK-A" pin definition, my design worked. I added "CLK-A" back to the design on another pin". I got "CLK_A<pin name>" in the "header.h" file. The first pin defined seemed to have priority.  

Hi all, I've been using CubeIDE for a little while and decided to build my next project using the STM32 VSCode extensions, which I am still figuring out. I am also figuring out CMake for the first time, as I let CubeIDE handle all the build details previously. In the past, CubeIDE let me add .h and .c files through the UI and automatically added them to the build process. I've found that I can make my own files and still build by manually altering the CMakeLists.txt file under the stm32cubemx directory, but I find myself editing the ioc file often enough that I'd rather not do this every single time I want to make a small change, and as the project size grows. All the drivers I've needed so far are part of CubeMX's middlewares, but if I do download a third party driver I foresee this becoming an issue there as well. Are there any workarounds to include manual additions to the generated CMake file? I'd like to utilize an STM feature if possible before I try making my own cmake file

Create a FreeRTOS project, keeping all settings at default configuration. Use CMake for building. The steps for creating the project are as follows:When the first task is initiated, a large number of recursive functions will appear in the function call stack.  

I found what looks like a reproducible STM32CubeMX code generation bug for STM32H5 USBX device projects.I tested this on a fresh project, so this does not appear to be a migration issue from an older codebase.ProblemCubeMX generates these USBX init functions:MX_USBX_Init()MX_USBX_Device_Init()MX_USBX_Device_Stack_Init()However, the generated call flow only invokes:MX_USBX_Init()MX_USBX_Device_Init()and never calls MX_USBX_Device_Stack_Init().That is a problem because MX_USBX_Device_Stack_Init() contains the actual device stack setup:ux_device_stack_initialize(...)class registrationux_dcd_stm32_initialize(...)Without that function running, the USB peripheral can start and receive a reset interrupt, but USBX has not been given valid device framework pointers yet.Observed failureWhen USB_DRD_FS_IRQHandler() fires and the USB reset path runs, the code eventually reaches:HAL_PCD_ResetCallback()_ux_dcd_stm32_initialize_complete()_ux_utility_descriptor_parse(...)and h