STM32CubeMX (MCUs)

This warning is occurring in the STM32U5xx HAL driver's low-level ADC header file (stm32u5xx_ll_adc.h). The warning indicates there's a self-assignment of a variable analog_wd_monit_channels where a variable is being assigned to itself. STM32CubeMX/Target_1/STM32CubeMX/Drivers/STM32U5xx_HAL_Driver/Inc/stm32u5xx_ll_adc.h:6920:34: warning: explicitly assigning value of variable of type 'uint32_t' (aka 'unsigned int') to itself [-Wself-assign]6920 | analog_wd_monit_channels = analog_wd_monit_channels;| ~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~1 warning generated.

I purchased a NUCLEO-U575ZI-Q and I noticed when I create a new project using the board selector and then create a new project with the MCU selector, I get different results in the IOC files which I think are causing me issues.This is the NUCLEO IOC:This is the MCU IOC:As you can see, Pin 36 is different between the two IOC's.  Obviously PA2 and PA3 are different interrupts.  I have my CC1101 connected to Pin 36.The datasheet shows Pin 36 as PA3. The code that is being generated for the MCU IOC is assigning Pin 36 to PA2:#define MCU_RF_GDO0_INT_Pin GPIO_PIN_2 #define MCU_RF_GDO0_INT_GPIO_Port GPIOA The code being generated for the NUCLEO IOC seems to match the datasheet: #define MCU_RF_GDO0_INT_Pin GPIO_PIN_3 #define MCU_RF_GDO0_INT_GPIO_Port GPIOA In the MCU IOC generated project, I don't get an interrupt. Both IOC's are using the same firmware version, STM32Cube FW_U5 V1.8.0. STM32CubeMX v6.15.0 shows the same results.Is there a way to fix this?Kindest r

Hello everyone.Why does the behavior of the while loop I wrote differ from the one generated by STM32CubeMX? Since the code generated by STM32CubeMX is highly abstracted, is it possible that even the same while loop behaves differently due to internal processing? Where can I learn about such rules? I'm a beginner, so I would really appreciate any guidance. If anyone knows, I would be grateful for your help. Here are the details of the issue. 1. When code is written inside the while loop generated by STM32CubeIDECode:Result: It doesn't work correctly. It seems that something inside the while loop isn't functioning properly.2. When code is written inside the while loop wrote by myself.Code: Result: It works correctly     

Using STM32H7R3L8HxH with external Flash and PSRAM. STM32CubeIDE version is 1.19.0 MxCube version is 6.15.0.MX XSPI1 and XSPI2 initialization functions do not set sXspiManagerCfg.Req2AckTime value. Here is XSPI1 code:static void MX_XSPI1_Init(void) { /* USER CODE BEGIN XSPI1_Init 0 */ /* USER CODE END XSPI1_Init 0 */ XSPIM_CfgTypeDef sXspiManagerCfg = {0}; /* USER CODE BEGIN XSPI1_Init 1 */ /* USER CODE END XSPI1_Init 1 */ /* XSPI1 parameter configuration*/ hxspi1.Instance = XSPI1; hxspi1.Init.FifoThresholdByte = 2; hxspi1.Init.MemoryMode = HAL_XSPI_SINGLE_MEM; hxspi1.Init.MemoryType = HAL_XSPI_MEMTYPE_APMEM_16BITS; hxspi1.Init.MemorySize = HAL_XSPI_SIZE_256MB; hxspi1.Init.ChipSelectHighTimeCycle = 5; hxspi1.Init.FreeRunningClock = HAL_XSPI_FREERUNCLK_DISABLE; hxspi1.Init.ClockMode = HAL_XSPI_CLOCK_MODE_0; hxspi1.Init.WrapSize = HAL_XSPI_WRAP_32_BYTES; hxspi1.Init.ClockPrescaler = 0; hxspi1.Init.SampleShifting = HAL_XSPI_SAMPLE_SHIFT_NONE; hxspi1.Init.DelayHoldQu

hello, I usually design borad with stm32g474vet6, i use USB VCP as serial debug port, juse insert to usb port of PC, then can use printf to print debug information. this time, i want to use threadX OS, that is, AZRTOS, when i config AZRTOS with stm32cubeMX, i found you can only choose one item, if you use AZRTOS, you can not use USB VCP, if you use USB VCP, you cannot use AZRTOS.why?here is picture for choose item.i config USB port for Device and CDC, but cannot.Thanks, 

..

I have the following settings in Cube Mx for TIM1The TIM1 is used for PWM generation, but the slave mode, trigger source, clock source are disabled then how Tim1 receives the clock for pwm generation.For TIM4 it is clearly statedSo i assume it will be taken from APB2 timer clock.One final questionIt is mentioned TRGO2 as above but how do i know it is connected to what? Please help.

I am working with the STM32C092CCTx microcontroller and have configured USART2 in asynchronous mode using STM32CubeMX. The system clock (SYSCLK), HCLK, and PCLK1 are all set to 48 MHz. USART2 TX/RX pins are correctly assigned with their alternate functions, and the peripheral is initialized using HAL.However, I do not see the USART2 clock source (clock mux) option in the Clock Configuration tab. I would like to confirm whether, for this STM32C0 series device, USART2 is fixed to use PCLK1 as its clock source — and whether the absence of the clock mux option is expected behavior in CubeMX for this MCU.Despite calling HAL_UART_Transmit() with valid parameters and configuring the baud rate to 115200 bps, I am not observing any data on the TX line. All clock and GPIO configurations appear correct. Could this be related to an internal clocking issue, or is there another possible misconfiguration I should look into?Any guidance on this would be greatly appreciated.

Hi all,Recently I faced pretty bug in the HAL implementation. I am using STM32F103 with CubeMx 6.12.1 HAL, (but inside the SPI C-code I saw 2016th year).SPI configured as Full-Duplex slave (using HW NSS, but it's doesn't matter).Sometimes I had to abort a transaction, and after the abort I got HardFault.Bug repeat sequence is:1. Start SPI Rx over Interrupt2. Abort Rx3. Start SPI Tx over interrupt4. Wait for receive all bytesAfter figuring out, I found, that Abort handler does not clear SPI_CR2_TXEIE and SPI_CR2_RXNEIE flags in the SPIx_CR2 reg.Therefore, after start Tx after Rx aborted, hspi->RxISR clears to NULL, but opposite TXIE flag kept set.Then on an any byte completion the condition on stm32f1xx_hal_cpi.c:2447 appears true, but hspi->RxISR already set to NULL, which raises HardFault.My proposal is:1. Clear xxIE flags during Abort (to fix exact this bug)2. Use HAL_SPI_ErrorCallback instead of NULL everywhere when hspi->RxISR and hspi->TxISR is setting to state wh

I see it's been a while but I ran into this today. Apparently system_stm32g4xx.c that is automatically generated by STM32MX no longer sets SCB->VTOR unless you define USER_VECT_TAB_ADDRESS in that file. When programming that doesn't cause an issue but it does stop you from debugging if interrupts are enabled. I wasted half a day of my life on this today. I don't know what benefit ST thought we'd get by changing this but breaking debugging for their customers they probably wasted a lot of the world's time. An awful lot of people were used to being able to generate code and use the debugger without modifying an autogenerated file they'd never needed to modify before. Edit: moved from HAL_Delay() --> SysTick_Handler never be called to a new thread.

We develop firmware on STM32H7R3L8HxH.STM32CubeIDE version is 1.19.0MxCube version is 6.15.0The problem is that code generator creates additional wrong include file for "regular" H7 MCUs:#include "stm32h7rsxx_hal.h" #include "stm32h7xx_hal.h"As this second file does not exist, compiler gives error:fatal error: stm32h7xx_hal.h: No such file or directoryIn application project it appears in main.hIn bootloader project the issue does not appear, but there is a blank line instead.In extmemloader project it appears in extmemloader_init.h Had same problem already STM32CubeIDE v1.18 and we have been manually fixing it (by removing bad include) so far, but it appears that it won't get fixed by itself so I report the issue now.

When upgrading to versions 6.13 and 6.14, regenerating the project would force the file encoding to UTF-8, causing garbled Chinese comments. However, adding a line -Dfile.encoding=GBK in the STM32CubeMX.l4j.ini file under the installation folder could solve the problem. But after upgrading to version 6.15, this command seems to have become ineffective. Even if the system variable is added, the regenerated code will still be forced to UTF-8 encoding. Using UTF-8 is rather troublesome. Does anyone know how to change it to GBK encoding?

When I try to select which channel gets a watchdog, it only gives me one option on the pull down. Instead, if I want to change the channel, I have to unselect all the ADC channels and make sure that the watchdog intended channel is the first one selected. Is this normal? From the photo above, only one channel is always available in the pull down.

Dear STMicroelectronics Support Team, I hope this message finds you well. I would like to report a clock configuration issue encountered when working with TouchGFX and STM32CubeMX for the STM32F746G-DISCO board. When creating a project using TouchGFX and selecting the STM32F746G-DISCO board, everything works as expected initially. However, after opening the project in STM32CubeMX and enabling the SDMMC interface, the tool prompts to "Resolve clock issues." Upon accepting the proposed solution, CubeMX automatically modifies the clock configuration in a way that alters the LTDC (TFT LCD) pixel clock from its original value of 9.6 MHz to a different value. As a result, the display no longer renders correctly. After investigation, I realized that the auto-resolve feature in CubeMX does not preserve the required clock settings for the display, and instead prioritizes SDMMC configuration. To fix this, manual fine-tuning of the clock tree is required to ensure the LTD

when I use V6.14.1 everything goes well, bug when I update to V6.15,the same IOC file shows LTDC RGB565 confict with usart2, when I disabled usart2, re-enabled LTDC RGB565,LTDC_R1 pin come out but no R0,R2, it must be a bug here!

I'm developing an app on the demo board STM32U5A9J-DKI've created the project from TouchGFX 4.25.0 project STM32U5A9J-DK FreeRTOSIt perfectly works, compile and debug with both TouchGFX and CubeIDE 1.18.1I then opened the .ioc file of the project with Open CubeMX 6.14.1. It says the project was set up with 6.14.0 and FW_U5 V1.7.0, so I migrated it.I've updated the Software Packs from X-CUBE-FREERTOS 1.0.0 to 1.3.1. CubeMX says no issue found and upgraded.Then I generated the code. There, the new code rewrote the app_freertos.c file deleting the initialization of the TouchGFX task/* Definitions for defaultTask */ osThreadId_t defaultTaskHandle; const osThreadAttr_t defaultTask_attributes = { .name = "defaultTask", .priority = (osPriority_t) osPriorityNormal, .stack_size = 128 * 4 }; /* Definitions for GUI_Task */ osThreadId_t GUI_TaskHandle; const osThreadAttr_t GUI_Task_attributes = { .name = "GUI_Task", .priority = (osPriority_t) osPriorityNormal, .

When I use CubeMX, the default language of my genereted code is C. I would like to develop in C++, as I can do in STM32CubeIDE. (I want to use VSCode to program)Is there any option to do this? I've tried just change the main.c to main.cpp, but it didn't work.(I'm a noob. So, if this questions is elementar, please, let me know likewise).

I just upgraded STM32CubeIDE from 1.17 to 1.19 which in turn upgraded MX from 6.13 to 6.15Prior to updating, in MX Clock Configuration I could clock the SPI system on the STM32H533 at the same rate as the CPU clock (250 MHz with no error). Now, to avoid the configuration error, I have to reduce it to 125 MHz.My code ran fine at 250 MHz in the previous version. IS THIS A FIX OR A BUG?Thanks!

In my project for an STM32H7S3, I have a number of GPIO settings.However, every time I open the file, one particular pin has its settings reverted to the defaults.Also, if I save the IOC file without making any changes at all, I can see in the diff that the settings for that pin have been removed:I'm currently using Cube 6.15.0, though this file was created with an earlier version.I'm not willing to share my IOC file here, though I'd be happy to send it privately to someone at ST.(See also another post by me about settings being lost without any action on my part.)Thank you.

Hello everybody,I am trying to generate a project for the STM32H7S78 using the latest version of STM32CubeMX. However, when I click on "Generate Code", the process stops at "Copying library files" and does not proceed any further.I usually work with IAR Embedded Workbench for ARM (v9.40.2), but I also tried using STM32CubeIDE, and the issue occurs there as well.Do you have any idea how to solve this problem?Thank you very much in advance! 

I cannot enable DCMI for STM32H753ZIT in STM32CubeMX version 6.15.0. I'd assume DCMI can be indeed used and that this is just a bug on CubeMX's part, but I'd like to verify before I do any orders. Related:- https://community.st.com/t5/stm32-mcus-products/minimum-clock-speed-and-enabling-pssi-problem/td-p/709772- https://community.st.com/t5/stm32cubeide-mcus/dcmi-cannot-be-used-on-the-latest-revision-cubeide-1-15-1-with/td-p/691876

Operating System: Windows 10STM32CubeMX version: 6.10.0STM32CubeU5 Firmware Package V1.4.0 / 20-October-2023When I attempt to validate my X-CUBE-AI model on target, I receive the following pop-up:Exploring STM32CubeMX.log shows the following warning:[WARN] IP:2119 - SRAM6PowerDownInRunMode not found: check if there is a RefParameter without a condition.The U5A5 doesn't even have an SRAM6, if I am reading the datasheet correctly.  When I look at the configuration options in CubeMX, I can't see anything for SRAM6 in the PWR section.

We have run into an issue with the NetXduo driver in V1.5.0 for the STM32H5 series (and maybe others, we did not check).WhatWhen IGMP is enabled (to allow reception of multicast messages), the reception of broadcast messages gets disabled. This breaks basic network functionality like ARP, making the device unreachable for others on the network.WhyIn the NetX driver (Middlewares/ST/netxduo/common/drivers/ethernet/nx_stm32_eth_driver.c), there is a structure called FilterConfig. Line 1500 sets the member FilterConfig.BroadcastFilter to ENABLE - which will be interpreted by the HAL to configure the broadcast filter in the ETH preipheral (Bit 5/DBF in register ETH_MACPFR on the STM32H573 used here).The structure is not used until a call to nx_igmp_enable() trickles down to _nx_driver_hardware_multicast_join() in the driver, at which point a different bit (to allow multicast reception) is flipped and the configuration is applied. Now multicast works, but pretty much nothing e

Hi,I'm using a STM32f767ZIT with FreeRTOS and LWIP on a custom board.After running into some weird UDP transmission issues, I discoverd that in the generated ethernetif.c file, the DCache is not cleaned in the low_level_output function.Adding this at line 414 ( after Txbuffer[i].len = q->len; ) in low_level_output() fixed my issues.SCB_CleanDCache_by_Addr(    (uint32_t *)((uint32_t)(Txbuffer[i].buffer) & ~0x1F),    Txbuffer[i].len + ((uint32_t)(Txbuffer[i].buffer) & 0x1F));In the HAL_ETH_RxLinkCallback, the SCB_InvalidateDCache_by_Addr is used, so this seems like an oversight?

arm-none-eabi-gcc -mcpu=cortex-m4 -g3 -DDEBUG -c -x assembler-with-cpp -MMD -MP -MF"Core/Startup/startup_stm32f429igtx.d" -MT"Core/Startup/startup_stm32f429igtx.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Startup/startup_stm32f429igtx.o" "../Core/Startup/startup_stm32f429igtx.s"arm-none-eabi-gcc "../Core/Src/eth.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DUSE_HAL_DRIVER -DSTM32F429xx -c -I../Core/Inc -I../Drivers/STM32F4xx_HAL_Driver/Inc -I../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Drivers/CMSIS/Include -I../LWIP/App -I../LWIP/Target -I../Middlewares/Third_Party/LwIP/src/include -I../Middlewares/Third_Party/LwIP/system -I../Drivers/BSP/Components/lan8742 -I../Middlewares/Third_Party/LwIP/src/include/netif/ppp -I../Middlewares/Third_Party/LwIP/src/include/lwip -I../Middlewares/Third_Party/LwIP/src/include/lwip/apps -I../Middlewares/Third_Party/LwIP/src/include/lwip/priv -I../Middlewares/Third_Party/LwIP/sr