Solved

With the attached ioc, CubeMx 6.17.0 freezes when I click on "Generate Code" on macos 14.8.3 . If I start it from the command line I can see this error in the console:2026-03-09 17:20:52,902 [INFO] UtilMem:75 - End SaveConfig() Used Memory: 550133736 Bytes (1459617792)2026-03-09 17:20:52,976 [INFO] UtilMem:75 - End SaveConfig() Used Memory: 580273760 Bytes (1459617792)2026-03-09 17:20:53,182 [INFO] ProjectBuilder:603 - [PM] Start Project Generation Thread2026-03-09 17:20:53,207 [INFO] IPsOverviews:2785 - set Specific Code input for plugin: RCC2026-03-09 17:20:53,207 [INFO] IPsOverviews:2785 - set Specific Code input for plugin: I2C2026-03-09 17:20:53,207 [INFO] IPsOverviews:2785 - set Specific Code input for plugin: I2C2026-03-09 17:20:53,207 [INFO] IPsOverviews:2785 - set Specific Code input for plugin: USART2026-03-09 17:20:53,207 [INFO] IPsOverviews:2785 - set Specific Code input for plugin: MEMORYMAP2026-03-09 17:20:53,207 [INFO] IPsOverviews:2785 - set Specific Code input for plug

Hello, I was going through the schematic of STM32U5G9J-DK1 where I came across the unused LDO (U19) for generating 1.8 V on this board. I wanted to know the significance of this LDO and what were the reasons to keep it unpopulated?Also, can I expect to see an improvement in the driving capability of this rail in case I wish to populate U19 with TPS76301? If yes, which orderable part no. of the same would be recommended?

  Hi everyone,I think STM32CubeMX is generating an incorrect configuration for STM32L071.In CubeMX → System Core → SYS → System power supply,I selected Power Regulator = SMPS (instead of LDO) and generated the project.After code generation, I get build errors because CubeMX inserts code that does not exist for this device / HAL package:In stm32l0xx_hal_msp.c, I see references like: HAL_PWREx_ConfigSupply(...) PWR_SMPS_SUPPLY But for STM32L0 / my CubeL0 HAL, these are not definedMy version is :

When choosing SmartCard mode for USART, parameter Parity is automatically set to Even. However generated code in usart.c, does not has:hsmartcard1.Init.Parity = SMARTCARD_PARITY_EVEN;Only when I manually reselect that in GUI, the parity will be set in the generated code.I am using Nucleo-G0B1RE.

Hello,I have been trying to configure the ethernet RMII with PTP synchro on cube MX. The idea is to link the PPS signal to trigger the timer. I can't manage to get the remap to be done to the ETH_PTP_PPS as is not displayed in the dropdown. According to the same cube mx that option should appear. On a side note when I enable the RMII_PTP_syncro I also loose all the config information of ethernet which i find rather strange. Do any of you have any suggestions on what's the proper way of configuring this? Is this even possible or is just a bug of the prompt that implies is possible? Thanks in advance ;)

Hello,  Began learning STM32 MCUs with my Nucleo-H753ZI board and I think I found a bug. The IO configurator on CubeIDE thinks user LED2 is on PB7 and is blue coloured. I'll paste the code it generates below. But in fact, the user manual UM2407 says user LED2 is on PE1 and is yellow coloured, which is indeed correct. Generated code from CubeIDE for Nucleo-H753ZI:#define LED2_PIN GPIO_PIN_7 #define LED2_GPIO_PORT GPIOB Appears to be a bug that should be fixed in the BSP.

HiAccording to the reference manual the high-cycle capable Flash of a STM32H562 is mapped to the address 0x0900_0000 to 0x0901_7FFF. The Memory Management Tool of CubeMX does not allow me to generate a Region in this address range (see Error below). Is this correct or should CubeMX not allow the generation of a memory region in this range? The Flash Option Byte was configured for the use of the high-cycle Flash.As a work around I can of course manually edit the linker script.I use STM32CubeMX Version 6.14 with the Firmware Package V1.5.0 to generate a STM32CubeIDE project on Windows 11.  

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,I am using a STM32MP257 (Karo SOM), RGMII connected to a DP83869 (100Mbps fiber mode).This is working well until I start the LVDS screen on my board.The screen is powered with 2 regulators :  Backlight (16V/360mA, dedicated boost) Logic (2.7V/500mA, dedicated buck)The DP83869 is powered with 3 regulators :1.1V (dedicated buck) 2.5V (dedicated LDO) 3.3V (shared buck also powering the MP2 SOM)Below is the behavior in different configurations:Screen unplugged => fiber link OK Screen plugged => fiber link KO hot-unplugging the screen makes the link working instantly Screen unplugged, flat cable present, with 100ohm R at the end of the LVDS signals => OK Screen unplugged,  With no current on the BL / logic DC/DC converter => OK Sinking 300mA on the BL => KO Removing the sink current makes the link working instantly Sinking 300mA on the logic => KO Removing the sink current makes the link working instantly Probing power rails with a scope show clean signals,

MCU: STM32H563VITx Stm32CubeMX version: 6.14.0 HAL Driver version: 1.5.0 When I enable EDATA option bytes in CubeMX, it generates the following code: void MX_FLASH_Init(void) { /* USER CODE BEGIN FLASH_Init 0 */ /* USER CODE END FLASH_Init 0 */ FLASH_OBProgramInitTypeDef pOBInit = {0}; /* USER CODE BEGIN FLASH_Init 1 */ /* USER CODE END FLASH_Init 1 */ if (HAL_FLASH_Unlock() != HAL_OK) { Error_Handler(); } /* Option Bytes settings */ if (HAL_FLASH_OB_Unlock() != HAL_OK) { Error_Handler(); } pOBInit.OptionType = OPTIONBYTE_EDATA; pOBInit.Banks = FLASH_BANK_2; pOBInit.EDATASize = 2; if (HAL_FLASHEx_OBProgram(&pOBInit) != HAL_OK) { Error_Handler(); } if (HAL_FLASH_OB_Lock() != HAL_OK) { Error_Handler(); } if (HAL_FLASH_Lock() != HAL_OK) { Error_Handler(); } /* Launch Option Bytes Loading */ /*HAL_FLASH_OB_Launch(); */ /* USER CODE BEGIN FLASH_Init 2 */ /* USER CODE END FLASH_Init 2 */ }​ The function does not launch

Cross selector displays operation frequency of STM32H743II as 400MHz, but it should be 480MHz. I've refreshed all data and databases but the result is the same. Is there a known solution for this issue? 

I'm trying to configure DMA in Memory-to-Peripheral mode for the STM32WB09KE, specifically to transfer data from memory to a Timer channel (TIM2_CH3 for Addressable LED's). However, in STM32CubeMX, I cannot see the expected DMA options under the DMA Settings tab for my Timer.    

Cube MX v6.17.0 and even previous version v6.16.1 have a problem generating SystemIsolation_Config for STM32N6.I made a test IOC file. There are 3 SECURE checkboxes checked in RIF -> RIF Aware IPs -> EXTI1:Line 13 for  EXTI13Line 17 for RTC secure-wakeupLine 62 for Wake-up PIN3Screenshot: Generated SystemIsolation_Config(void) in main.c of FSBL contains: /* set up EXTI configuration */ /* EXTI13 line */ HAL_EXTI_ConfigLineAttributes(13,EXTI_LINE_SEC|EXTI_LINE_NPRIV); /* RTC secure wake-up line */ HAL_EXTI_ConfigLineAttributes(17,EXTI_LINE_SEC|EXTI_LINE_NPRIV); /* Wake-up_PIN3 line */ HAL_EXTI_ConfigLineAttributes(62,EXTI_LINE_SEC|EXTI_LINE_NPRIV);These calls fail in this assert in stm32n6xx_hal_exti.c: assert_param(IS_EXTI_LINE(ExtiLine));Full assert is turned on in IOC so it lands in assert_failed.The assert condition check macro is very messy, but it appears like it expects type and register mask with it so I added them (based on table 138. EXTI line connec

在使用最新版本的CubeMX 6.17.0 配置STM32G474QETx系列的HRTIM时，Dead Time明明没有启用，但是显示TA2的置位输出源无法配置。

All related to the deadtime settings are disabled, but the Set Source of Output 2 can't be set up. It keeps constant 0, and says the deadtime is enabled? why??? @Aimen1

Hi,I found an issue when generating code for a BLE application with STM32CubeMX v6.17.0.In particular, I have a service called DataTransferService with three characteristics:DataStreamCommandControlTransferStatusThe DataStream characteristic is configured as a notification with a fixed value length of 100 bytes.When I try to increase its length up to 250 bytes and regenerate the code, the following functions in custom_app.c are removed:Custom_Datastream_Update_Char()Custom_Datastream_Send_Notification()I have attached the .ioc file for reference.

Code generation of the attached .ioc file (copy of ST example file of similar name) does not generate clock init for UART4.  This means the example application hard faults.  I see no reason why the UART clock should not be initialised here and would save someone time debugging in the future!In stm32mp2xx_hal.c:void HAL_UART_MspInit(UART_HandleTypeDef* huart) { GPIO_InitTypeDef GPIO_InitStruct = {0}; if(huart->Instance==UART4) { /* USER CODE BEGIN UART4_MspInit 0 */ // TODO: Need this here! __HAL_RCC_UART4_CLK_ENABLE(); /* USER CODE END UART4_MspInit 0 */ /**UART4 GPIO Configuration PH8 ------> UART4_RX PH7 ------> UART4_TX */ GPIO_InitStruct.Pin = GPIO_PIN_8; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Alternate = GPIO_AF4_UART4; HAL_GPIO_Init(GPIOH, &GPIO_InitStruct); GPIO_InitStruct.Pin = GPIO_PIN_7; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Sp

When configuring the LTDC Layer Settings for an STM32N6 chip in CubeMX, the Layer 0 - Color Frame Buffer Start Address is missing: This parameter is available with other chips, such as STM32F750:

The STM32N6 supports YCbCr as an input format (see reference manual RM0486 section 21.3.5). As of version 6.16.1, this option is still not available in STM32CubeMX. The generated code can be manually modified to make it work by settinghdma2d.LayerCfg[x].InputColorMode = DMA2D_INPUT_YCBCR;   

CubeMX 6.16.0 "Memory Management" used for ethernet and with enabled linker file generation creates the following [ORIGIN adapted from default]:RxDescripSection (rwx) : ORIGIN = 0x30040000, LENGTH = 0K TxDescripSection (rwx) : ORIGIN = 0x30040060, LENGTH = 0K Rx_PoolSection (rwx) : ORIGIN = 0x30040200, LENGTH = 1KWhat I would have expected was:RxDescripSection (rwx) : ORIGIN = 0x30040000, LENGTH = 96 TxDescripSection (rwx) : ORIGIN = 0x30040060, LENGTH = 96 Rx_PoolSection (rwx) : ORIGIN = 0x30040200, LENGTH = 1536[with just 1 ETH RX buffer - see this other post ].Can someone explain to me whether this is intentional - maybe because of a constriction with the MPU granularity?Or whether CubeMX handles this wrong and should allow sub-kilo-byte granularity?Best regardsJohannes 

Hi,Good day,may we seek your expertise regarding L9959U/L9959T.is there any difference for these mpn below?L9959U-TR-D L9959T-TR-W L9959U-TR-W thank you.

Is this parameter dimensionless or in volts? I've tried many values, but I keep getting a yellow warning icon indicating an error, such as with 0 or 1 or 1.65 or 0.5 

Hi,My actual CubeMX v. 6.17 offers some updates, but these update are for Cube MX 6.18. Cube Mx 6.18 is not available yet. When can we expect the MX update ? St. 

Hi everyone,I am new to Android development, and I have two questions about OpenSTDroid v6.2.0.I followed the official documentation to build OpenSTDroid, but I encountered a build error. The details are shown in the attached error.txt.How to build OpenSTDroid distribution - stm32mpu   For OpenSTDroid, is the Device Tree workflow similar to Yocto? In other words, should the Device Tree be generated by STM32CubeMX and then integrated into the OpenSTDroid source tree?Any guidance or suggestions would be greatly appreciated.Thank you.

Hi,I am writing my own RTOS and I do not use CubeMX nor the HAL. I directly program the STM32N657 LTDC registers.The target is the STM32N6570-DK board with the original 800x480 RGB LCD.Problem descriptionThe LTDC background color is displayed perfectly.However, as soon as I enable Layer 1 with a framebuffer located in the internal AXI SRAM, the displayed image becomes corrupted.The corruption is unusual:the top of the image is correct, below approximately 320 lines, the image progressively becomes shifted, the bottom of the image looks like repeated square blocks shifted horizontally, no FIFO underrun is reported.The framebuffer contents themselves are correct when read back by the CPU.LTDC configurationFramebuffer:Address : 0x34200000Format : ARGB8888Size : 800 x 480Pitch : 3200 bytes Layer registers:L1CFBAR = 0x34200000L1CFBLR = 0x0C800C83L1CFBLNR = 480L1PFCR = 0x00000000 (ARGB8888)L1CACR = 0x000000FFL1BFCR = 0x00000607L1CR = 0x00000001 Global registers:GCR = 0x00