This page is your go-to destination for quick and practical advice across various issues related to STM32CubeMX.
1. STM32CubeMX Frequently Asked Questions
1.1. How can STM32CubeMx detects automatically Python's installation directory
To ensure seamless integration of Python with STM32CubeMX, it is recommended to select the "Add Python.exe to PATH" option during the Python installation process. This will make Python accessible from the command line, and STM32CubeMX will be able to locate the Python installation directory without manual configuration.
1.2. I have trouble authenticating to STM32CubeMX
If you have encountered an authentication problem while using STM32CubeMX, don't worry. You simply need to set your connection parameters. For more details see link below: https://community.st.com/t5/stm32-mcus/how-to-set-the-network-connection-parameters-for-stm32cubeide/ta-p/585694
1.3. I encountered a network connection error during a download from STM32CubeMX.
If you experienced a network connection issue during a download select Help > Updater
settings and verify the connection status.
If the Check connection button shows a green check mark (connection is up), click it. The
button should be refreshed to show a fuchsia cross (connection failed). Adjust the
parameters to match your network configuration and click the “Check connection” button
again. Once the green check mark appears (connection back up), you may proceed with the
download.
1.4. Since I changed my login to access the Internet, some software packs appear not available.
The workaround is to delete the .stm32cubemx folder from the user directory and re-launch
STM32CubeMX. Note that all software packs installed using the “From URL” button must be
re-installed.
Select Help > Updater settings:
- Check your repository path on the Updater Settings tab.
- If a proxy is used, enter your login and password information on the Connection Parameters tab.
1.5. On dual-context products, why some peripherals or middleware are not available for a given context?
Some peripherals and middleware require another peripheral or middleware to be enabled
in the same context.
For example, the LwIP middleware requires the ETH peripheral to be enabled in the same
context.
1.6. On the Pinout configuration panel, why does STM32CubeMX move some functions when I add a new peripheral mode?
You may have deselected . In this case, the tool performs an automatic remapping to optimize your placement.
1.7. How can I manually force a function remapping?
Use the Manual Remapping feature.
1.8. Why some pins are highlighted in yellow or in light green in the Pinout view? Why I cannot change the function of some pins (when I click some pins, nothing happens)?
These pins are specific pins (such as power supply or BOOT) which are not available as peripheral signals.
1.9. Why does the RTC multiplexer remain inactive on the Clock tree view?
To enable the RTC multiplexer the user must enable the RTC peripheral in the Pinout view
as indicated below.
1.10. How can I select LSE and HSE as clock source and change the frequency?
The LSE and HSE clocks become active once the RCC is configured as such in the Pinout view. See Figure 436 for an example. The clock source frequency can then be edited and the external source selected, see Figure 437.
1.11. Why STM32CubeMX does not allow me to configure?
PC13, PC14, PC15, and PI8 as outputs when one of them
is already configured as an output?
STM32CubeMX implements the restriction documented in the reference manuals as a footnote in the table detailing the output voltage characteristics:
PC13, PC14, PC15 and PI8 are supplied through the power switch. Since the switch only sinks a limited amount of current (3 mA), the use of GPIOs PC13 to PC15 and PI8 in output mode is limited: the speed should not exceed 2 MHz, with a maximum load of 30 pF, and these I/Os must not be used as a current source (e.g. to drive a LED).
1.12. Ethernet configuration: why cannot I specify DP83848 or LAN8742A in some cases?
For most series, STM32CubeMX adjusts the list of possible PHY component drivers
according to the selected Ethernet mode:
- when the Ethernet MII mode is selected the user is able to choose between the DP83848 component driver or a “User Phy”.
- when the Ethernet RMII mode is selected, the user is able to choose between the LAN8742A component driver or a “User Phy”.
When “User Phy” is selected, the user must manually include the component drivers to be used in its project.
Note: For STM32H7 series, the PHY is seen as an external component and is no longer specified under the Ethernet peripheral configuration. The user can select the PHY under LwIP Platform settings tab. However, as the STM32H7 firmware package provides only the driver code for the LAN8742A component available on all STM32H7 evaluation and Nucleo boards, the user interface offers only the choice between "User Phy" and LAN8742. When LAN8742 is selected, the BSP driver code is copied into the generated project.
1.13. How to fix MX_DMA_Init call rank in STM32CubeMX generated projects?
When DMA is used, the MX_DMA_Init shall always be called before any other HAL_***_Init (where *** is any peripheral with a HW dependency on DMA init code).
STM32CubeMX version 6.3.0 (STM32CubeIDE Version: 1.7.0 ) introduced a regression: initialization function calls were generated in the wrong order.
STM32CubeMX 6.4.0 fixed this issue for newly created projects. However, the calling order being saved in the project .ioc file, STM32CubeMX 6.3.0 generated projects will still show the issue when opened and re-generated with STM32CubeMX 6.4.0.
To fix the issue, open the saved .ioc file (already created with 6.3.0 version) with any text editor installed in your machine and delete the line: ProjectManager.functionlistsort=....
After saving the modification, re-open the .ioc file with STM32CubeMX version 6.4.0 (STM32CubeIDE Version: 1.8.0) or later. Through Project Manager view > Advanced
Settings tab, make sure that the initialization functions are correctly ordered and re-generate
your project.
1.14. When is the PeriphCommonClock_Config() function generated?
- When RCC is in LL mode, it is generated to initialize
- ckper clock, when used by a peripheral (for series having ckper)
- pll2, pll3, pllsai1, pllsai2, when used
- When RCC is in HAL mode it is generated to initialize
- pll2, pll3, pllsai1, pllsai2, when used by more than one peripheral
What are the conditions and reason for having this function? The reason is to do the split, e.g. the system clock in the system_clockConfig() function, and the RCC peripheral initialization in the HAL_mspInit/Mx_.._Init() function.
There is a difference between the generation when RCC is in HAL or LL mode because:
- in LL: we have the call to initialize the PLLs directly
- in HAL: we should at least initialize one peripheral
When PLL is used by only one peripheral the initialization is done in the HAL_mspInit/Mx_.._Init(), otherwise in the PeriphCommonClock_Config().
1.15. How to handle thread-safe solution in STM32CubeMX and STM32CubeIDE?
AN5731 “STM32CubeMX and STM32CubeIDE thread-safe solution” (available on www.st.com) contains a detailed description