Ask questions on STM32CubeMX. Discuss code generation and configuration challenges, among other topics.
Most recent activity
Hello @Khouloud ZEMMELI ,I have request with regards to TIMER_TASK_PRIORITY setting available under FreeRTOS -> Configuration Peripherals (with CMCIS V2 in use, which will set / Enable USE_TIMERS).I believe it is not a good practice to use a constant value for TIMER_TASK_PRIORITY. Below are my reasons for it.If user adds a new task with priority higher than the (FreeRTOS) TIMER TASK, the performance of the firmware will be impacted.In case a timer task is used by FreeRTOS it must have the highest priority compared to all other tasks priority. I believe such a check is possibly missing in the STM32CubeMX generated code.A user who is not aware of the use of the TIMER_TASK_PRIORITY setting might leave it at its default value (of 2). Thus the resulting firmware will have performance issues.What is currently working:I had earlier requested for setting of some UART and CAN configurations with help of macros. This was provided (possibly) with STM32CubeMX version 6.0.0. I do get a war
..
STM CubeIDE 1.6.1STM32F411FW_F4 V1.26.1Driver LLNo string added when initializing date "RTC_DateStruct.Day = xx;"Details:https://github.com/STMicroelectronics/STM32CubeF4/issues/74#issuecomment-893317794
I am resuming electronics as a hobby after a significant hiatus.STM32Cube, MX and IDE are both fine. But the programmer is continually crashing.I am on linux and have replaced the OpenJDK by the Oracle JDK, no easy task for me either ! $java -versionava version "16.0.2" 2021-07-20Java(TM) SE Runtime Environment (build 16.0.2+7-67)Java HotSpot(TM) 64-Bit Server VM (build 16.0.2+7-67, mixed mode, sharing)When I try to connect from a windows machine, all is good. But from linux when i try to connect, it crashes.Why should my next step be ?thankspete
As pointed out by @Markus GIRDLAND here, the MCUFinder (STM32CubeIDE v1.7.0) does not work with Wayland.X11 is being phased out and Wayland is supposedly better.Since both, STM32CubeIDE [v1.7.0 Build: 10852_20210715_0634 (UTC)] and STM32CubeMX (v6.3.0 RC5) work just fine with Wayland, is there anything in the pipeline for the MCUFinder?
Are there example MX projects? The IDE has xcellent example projects?
I am using the interfaces octospi1 and octospi2 to interface two qspi-nor flashes.The interfaces are configured the following way:Quad spi (octospi 1 uses low port 1 and octospi 2 uses low port 2)CLK (octospi 1 uses port 1 and octospi 2 uses port 2)NCS is disabled on both instances since I am using an external GPIO for this.After the second instance got initialized with the call to MX_OCTOSPI2_Init(); it appears that the first instance gets disabled in the octospi manager.I tracked the issue down to the check where the HAL_OSPIM_Config function verifies that there is no conflicting configuration between the two instances. Unfortunately this check does not respect the fact that some ports can be disabled and deactivates the other instance if both instances have the same ports disabled. As for example, in my example above, where the NCSPort, IOHighPort and DQSPort are disabled for both instances.This should not be the case since this is clearly not a conflicting situation in my opinion.
version: 1.5.1MCU: STM32F446RETx
Previously I posted that I need MASTER Timer enabled so that the HRTIM1E interrupt would occur in H747.https://community.st.com/s/question/0D53W00000UfL6uSAF/hrtime1-interrupt-not-firingIt turns out that it is similar to G474.The code generated by CubeMX is wrong.As shown below, I enable interrupt source on timer repetition. but the code generated ispTimerCfg.InterruptRequests = HRTIM_MASTER_IT_NONE;Also notice that it is the definition for MasterTimer while I am using TimE and MasterTim is not enabled.So, I need to overwrite manually withpTimerCfg.InterruptRequests = HRTIM_TIM_IT_REP;Pls try to fix.
point 1) "DAC_InitStruct.WaveAutoGenerationConfig = __LL_DAC_FORMAT_SAWTOOTHWAVECONFIGPOLARITYRESET_DATASTEP_DATA;" should be " DAC_InitStruct.WaveAutoGenerationConfig = __LL_DAC_FORMAT_SAWTOOTHWAVECONFIG(LL_DAC_SAWTOOTH_POLARITY_DECREMENT, 2000, 100);"point 2) should insert "DAC_InitStruct.WaveAutoGenerationConfig = __LL_DAC_FORMAT_SAWTOOTHWAVECONFIG(LL_DAC_SAWTOOTH_POLARITY_DECREMENT, 4000, 200);"
This is an everlasting bug of STM32CubeMX since v6.x release. After installing the latest v6.2.1 and trying to open IOC file (STM32H745BI MCU) creaded with previous version v5.x of CubeMX one gets unknown error window shown in the attachment.It does not matter if I try to open the project right away after running CubeMX or after creating a dummy project. This problem happens both in Ubuntu 18.04 as well as in Windows 7 professional.Does the ST team ever plan to fix this? CubeMX v6.x seems useless.Thanks for any feedback
@STM32 MCUs In our project we use USB_CDC. We don't use VBUS, disabled at all places in CubeMX, as far as I can see.Now we want to add an external interrupt on PC0. I have done this.CubeMX generates the following code, already before I added external interrupt:usbd_conf.c/** * @brief Handle USB VBUS detection upon external interrupt * @param GPIO_Pin * @retval None */void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin){ if (GPIO_Pin == GPIO_PIN_9) { HAL_PCDEx_BCD_VBUSDetect(&hpcd_USB_OTG_FS); }}This function is needed to define a callback for the external interrupt.Because I have disable VBUS, I assume this function shall not be in generated code?I found the same bug report already a few times in forum, partly going back to 2018.https://community.st.com/s/global-search/HAL_GPIO_EXTI_Callback?t=1616688548492Why was it not yet fixed? The bug reports from the past are closed,but how was the fix?Best regards,Marie
Edit: I managed to narrow this down and create a reproducible, minimal example.Posted as bug-report here: https://community.st.com/s/question/0D53W000011uLtPSAU/stm32h7-cubemx-critical-codegeneration-bug-rccllIn my opinion the CubeMX generated clock initialization is in the wrong order and this seems to potentially cause hardfaults.Consider following example configuration:This should be valid according to CubeMX and my understanding. BUT:In the initilaization code, CubeMX *first* picks the PLL as system clock and only afterwards sets the prescalers.Generated code (SystemClock_Config):[...] /* Wait till PLL is ready */ while (LL_RCC_PLL1_IsReady() != 1) {} /* Intermediate AHB prescaler 2 when target frequency clock is higher than 80 MHz */ LL_RCC_SetAHBPrescaler(LL_RCC_AHB_DIV_2); LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL1); LL_RCC_SetSysPrescaler(LL_RCC_SYSCLK_DIV_2); LL_RCC_SetAHBPrescaler(LL_RCC_AHB_DIV_2); LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_2); LL_R
When I enable a peripheral like LTDC - the pins automatically get assigned. I would prefer to assign them manually so that I can have all related signals come out from a single side of the LQFP. How can I do this? Or is this not advised?
there is some code left out of the Cube initialisation that causes this issueplease put this back in...using L432 today, but this issue is a HAL problem.This corrected function fixes this issue. ( thanks to stack overflow)https://stackoverflow.com/questions/56490843/what-is-issue-with-stm32-virtual-com-port-i-can-not-open-it/** * @brief Manage the CDC class requests * @param cmd: Command code * @param pbuf: Buffer containing command data (request parameters) * @param length: Number of data to be sent (in bytes) * @retval Result of the operation: USBD_OK if all operations are OK else USBD_FAIL */ static int8_t CDC_Control_FS(uint8_t cmd, uint8_t* pbuf, uint16_t length) { /* USER CODE BEGIN 5 */ static uint8_t lineCoding[7] // 115200bps, 1stop, no parity, 8bit = { 0x00, 0xC2, 0x01, 0x00, 0x00, 0x00, 0x08 }; switch(cmd) { case CDC_SEND_ENCAPSULATED_COMMAND: break; case CDC_GET_ENCAPSULATED_RESPONSE: break; case CDC_SET_COMM_FEATURE:
Hi everyone!I'm trying to use STM32H723 in QUAD SPI mode.CubeMX does project generation but when I trying to compile project at Keil an error appears about undeclared "GPIO_AF4_OCTOSPIM".If I changed it to GPIO_AF4_OCTOSPIM_P1 compilation run without errors. But how I could know that I chose correct define or not?Other question about commands to work with memory, which HAL command and it what sequence for READ/WRITE/STATUS CHECK in this mode?I cannot find examples from STM to test and revise my code.
Hi,there is probably small bug when generating project STM32CubeIDE using LwIP stack. In file LWIP/App/lwip.c, there is duplicate user code section 4_3. This is present twice (on lines 113 and 151):/* USER CODE BEGIN 4_3 */ /* USER CODE END 4_3 */First is in function static void Ethernet_Link_Periodic_Handle(struct netif *netif), second is in function void MX_LWIP_Process(void). This means that all the code, that is written to the upper section, is after code generation duplicated to the lower one. Its not a big issue but it is annoying to correct it after every code generation.I use STM32CubeIDE: CubeMX version: Firmware Package Name and Version : STM32Cube FW_H7 V1.9.0Karel
I use user constants in projects entered in CubeMX window. I found two isues with latest MX.When i open ioc file in CubeIDE firstly after open IDE , then i see user constants OK, but when i move in some settings or close generate and reopen, my constants isnt showed and when i add new old is removed from ioc file.MX incode checking dont use defined constants and generate error for example in DSI HOST i define user value PACKSIZE 640 and place it to Burst mode packet size ...
A couple versions back STM32Cube placed the BDMA_Init() early in the initialization code using my IOC file, later versions of Cube (5.1, 5.2) place it near the end. For a reason unknown to me if it is placed near the end the BDMA callbacks will never get called, but if it is placed before the MX_DMA_Init() function it works. I haven't tried to figure it out since I can work around it by moving the init function, but thought I'd point it out. /* Initialize all configured peripherals */ MX_GPIO_Init(); MX_BDMA_Init(); <-- Works when it's here MX_DMA_Init(); MX_MDMA_Init(); MX_ADC3_Init(); MX_ADC1_Init(); MX_ADC2_Init(); MX_SPI4_Init(); MX_I2C2_Init(); MX_I2C3_Init(); MX_FDCAN1_Init(); MX_TIM8_Init(); MX_TIM1_Init(); MX_TIM2_Init(); MX_TIM3_Init(); MX_TIM6_Init(); MX_TIM7_Init(); MX_USB_OTG_FS_PCD_Init(); /* Initialize all configured peripherals */ MX_GPIO_Init(); MX_DMA_Init()
I need advice on setting up I2S of ADXL317 IC.I am trying to set up using CUBEMX, but the timing is not correctBCLK is not 3.072Mhz, 2.12Mhz comes outAs shown in the picture below, what part settings need to be changed to match the timing?
I make my own custom board using STM32 MCU(ex Stm32f4 disco) so I want to store it's gpio clock settings all configuration next time I want to use this board then all settings are initialise automatically how can I do this?
The GUI interface for defining FreeRTOS tasks dictates that stack size is specified in words. That generates a call to CMSIS V2's osThreadNew() which requires attributes.stack_size to be specified in bytes. (The CMSIS layer then divides that by 4 to convert it back words before passing it to FreeRTOS which dictates it's specified in words).The GUI gets it right for Static tasks, but appears to get it wrong for Dynamic tasks. For example, the above selection in the GUI produces the following correct code for the static case. It declares the array to be 256 words long, and sets stack size to 1024 bytes.uint32_t bannerTaskBuffer[ 256 ]; osStaticThreadDef_t bannerTaskControlBlock; const osThreadAttr_t bannerTask_attributes = { .name = "bannerTask", .stack_mem = &bannerTaskBuffer[0], .stack_size = sizeof(bannerTaskBuffer),In contrast, the size for the dynamic task is passed through to .stack_size unchanged:const osThreadAttr_t defaultTask_attributes = { .name = "defaultTask", .prio
Stm32立方体生�?始终�?��?的开尔文件。�?管你等多久,它都无法�?��?。您必须�?新�?�动计算机�?能�?��?,但很快将�?次�?��?
hi :grinning_face: i tested several version of stm32CubeIDE for this,cubeMX inside stm32CubeIDE, is very slow working(exp: change pin name)but standalone stm32CubeMX, is normal work.Is there a solution to this? :\ #stm32CubeIDE #stm32CubeMX #stm32CubeMX:smiling_face_with_heart_eyes:
ST Community highlights – April to June 2026
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.