2025-08-25 7:36 AM
Dear STM32 Community,
We believe that the example projects provided for the STM32Cube embedded software are a valuable resource when developing projects.
We would like to better understand how developers use these examples in their workflow and explore ways to improve them. Therefore, we have a few questions we would like to ask:
From where do you obtain the examples, and why?
How do you use the examples in your work with STM32 embedded software?
What is working well, and what can we do to improve the examples and/or your experience working with them?
You can either reply directly in this thread or feel free to send me a private message.
Best regards,
Emil
2025-10-19 5:07 PM
Hello,
It would be nice if we can get the source code for the demos that come with the board. For example, where can i find the source code project for stm32n6570-dk board/development system?
thanks, Matt
2025-10-28 3:35 AM
For many STM32 Families, you have provided example codes with same topic. If i have one HID mouse example with USBX, i do not need another one. Again, if i have USBX MSC SRAM example for one chip, i do not need the same example for another chip. I would prefer USBX MSC SD Card example, in my experience, i faced numerous issues with SD card implementation.
2025-11-05 6:57 AM
It would be great to have a feature in the GENERATE CODE button for the CubeMX ioc file that allows users to freely reconfigure the USER CODE BEGIN and USER CODE END areas of their projects, as well as control the file names being operated on (such as main.c or linked_list.c).
I will use the CubeMX Example for sample source code. It is very convenient to deploy an Example project specialized for a certain function and update it with a single click of the GENERATE CODE button. However, I often find myself wanting to merge two or more Example ioc files. Unfortunately, there is no way to adjust the USER CODE BEGIN and USER CODE END areas, so I end up backing up the project as Project A and Project B, updating Project A using the GENERATE CODE button from the ioc file, and then checking the diff between Project A and Project B to manually transfer the differences back to the original project. This process is quite tedious.
When I update the driver version in CubeMX, I also back up the project as Project A and Project B, updating Project A with the old version of CubeMX and Project B with the new version, using the GENERATE CODE button. I then check the diff between Project A and Project B and manually transfer the differences back to the original project. However, the initialization order of GPIOs may change, resulting in a large number of diff differences, even though there are effectively no real differences. Manually transferring these differences back to the original project is quite a challenge.
Well, compared to the bare-metal sample code from the past, this environment feels like heaven, so I guess this is a luxurious complaint.
2025-11-11 1:42 PM
Hi Emil, I generally use examples provided by STM via STM32CubeIDE or other STM resources e.g., STM32Cube_FW_MP2_V1.2.0 for board STM32MP257F-DK... One thing that would be very helpful is for examples to included .ico files...
2025-11-11 2:13 PM
As far as I can tell, BSP packages and drivers do not use CubeMX .ico files and that .ico file does not exist. BSP packages, I think, were never intended to use CubeMX configuration and were never intended to be portable. They were intended to be "load this, run this, see how wonderful, buy product."
I do not use them at all, although you have to take the code, generate the ICO files yourself, use CubeMX to initialize the board the right way, then just use a fraction of the demo code. It can be done........
2026-01-13 9:45 AM - edited 2026-01-13 9:57 AM
Previously, I would use the examples as reference code from within CubeIDE. Now that CubeMX and CubeIDE are separated, I use the examples as reference code generated by CubeMX and used within CubeIDE.
I use the examples as running samples of peripherals that I have not worked with yet (LTDC, DSI, Ethernet), stuff that changes between processor families (code read locking sequences), and stuff that changes due to RTOS used and revs to the HAL (USB).
I don't prefer github because there seem to be two streams of code in ST's git ecosystem, the stuff that forms the HAL releases, and the other one. I'd rather deal with the stable release rather than, six months later, wondering where a particular fragment of code came from.
What can be improved? I understand that there are some people who prefer wearing shirts made of barbed wire and refuse to use HAL, GUIs, and compilers, not me, I like the Cube ecosystem because I've got applications to write. I'd like examples that use the tools, have ioc files, use HAL, use the RTOSs, use the security features. Add the extra stuff like memory management with ethernet, and rework the examples to show the best practices for getting ethernet and TCP/IP working. (one of my big complaints with IOT and embedded systems is the lack of usable networking examples, leading to people using Linux in their devices instead, resulting in ports being left open for botnet usage)
Oh, and the BSPs, I don't prefer them, they seem poorly documented and out of date and seem to be a bad choice to integrate into a system since they're not really HAL code and not something that I wrote or reviewed. Are they kept up to date? Were they reviewed? Who knows. Avoid.