Feature Request: Multi-Profile GPIO & Peripheral Configuration for Power Mode Transitions

[Ufuk.Akkaya]

Hello ST Community,

 

I am working on an ultra-low-power project using STM32 MCUs and I have a question regarding the current capabilities of STM32CubeMX.

 

Current Situation: I am aware that STM32CubeMX has an option to "Set unused pins to Analog" to save power. However, this is not sufficient for complex low-power management. In many cases, pins that are actively used in "Run" mode need to be reconfigured into specific states—not necessarily Analog—before entering a low-power mode (e.g., keeping a specific Pull-up/Pull-down for an external sensor, or maintaining a specific Output level to prevent leakage through external circuitry).

Currently, CubeMX generates a single initialization function (e.g., MX_GPIO_Init()). To manage transitions for these "used" pins, we must manually write wrapper functions to change their states before sleep and re-initialize them upon wake-up. This manual process is time-consuming and prone to configuration errors.

 

My Question: Is there an existing feature or workflow within CubeMX that allows users to define two or more different configuration sets for the same pins/peripherals and generate separate initialization functions for them?

 

Feature Suggestion: If this is not currently supported, I believe it would be a massive improvement for the STM32 ecosystem. Ideally, CubeMX could have a "Mode Manager" tab where:

• Users can define custom modes (e.g., Run_Mode, UltraLowPower_Mode).
• For each mode, the user can visually set GPIO states (Analog, Pull-up, Output levels, etc.) and peripheral states for all pins, not just the unused ones.
• CubeMX generates distinct functions like MX_GPIO_Init_Run() and MX_GPIO_Init_LowPower().

This would significantly reduce boilerplate code, prevent hardware-related leakage errors during manual transitions, and make power optimization much more intuitive.

I would love to hear if there are any workarounds or if this is something the dev team might consider for future releases.

Best regards,

[Ghofrane GSOURI]

Hello @Ufuk.Akkaya 

I'm currently checking your request . I will get back to you asap.

THX

Ghofrane

[Andrew Neil]

I agree that CubeMX is poor at this.

It basically seems to work on the assumption that you will just configure everything once, and then it stays that way.

See also: Configure RTC Alarm separately from RTC

 

---

@Ufuk.Akkaya wrote:

Is there an existing feature or workflow within CubeMX that allows users to define two or more different configuration sets for the same pins/peripherals and generate separate initialization functions for them?

---

I think not.

As a workaround, you could create separate CubeMX projects for the different configurations, then copy the generated code into one project.

[Ghofrane GSOURI]

Hello @Ufuk.Akkaya 

Your contribution is much appreciated.

Your change request has been raised to dev team under internal ticket ID 226565 for further investigation and feasibility check.

THX

Ghofrane

[Ufuk.Akkaya]

Thank you, @Ghofrane GSOURI 

I'm glad to hear the request has been raised to the dev team.

@Andrew, thanks for the tip. It’s a bit of extra maintenance, but it seems like the most viable workaround at the moment until we get a native solution.

 

Best regards

[Mikk Leini]

Related suggestion also here:
https://community.st.com/t5/stm32cubemx-mcus/new-ioc-file-format-suggestion/m-p/842058

I have worked with automotive AUTOSAR classic MCAL UI tools and libraries which is kind of like ARM CMSIS-Driver + ST HAL + STM32CubeMX. Those tools (at least some) support configuration sets to do hardware variant, device configuration and operating mode based run-time peripheral (re-)configuring. At the beginning it was amazing - we got stuff working fast. But I soon learned that the static and generated code was a massive macro monster with a lot of look-up tables and with a noticeable performance overhead. And even with that feature the projects still reached the generator tool capabilities and stuff had to be programmed manually.

There is also Zephyr RTOS which allows to define multiple hardware overlays which you can choose during init (maybe even runtime), but it's a massive beast also with its abstraction layers.

Even though it would be very nice to see such feature in CubeMX, and I give my Kudo also, I have doubts it fits every purpose. There is no such thing as a perfect tool. I believe it's more worth to make the generator and code customizable and extendable so engineers can tailor it without too much pain. The ecosystem is quite flexible already with pre- and post-generation script option, separated MX and HAL layer, and user sections in the MX code. It does need improvement, but compared to the rest of the ecosystems I've seen I say it's quite good. 

[Pavel A.]

> There is no such thing as a perfect tool.

The perfect tool is the AI coding assistant, these days. You just give it good instructions and it will write the code, and make sure that no pin is left out.

For example: "Create a function to re-initialize every GPIO pin of the MCU as specified below.

All pins not specified below initialize as Analog" or "If any pin is not specified below, prompt me for its mode".

"Create a test for the pin re-configuration in low power mode".  "Make the code compatible with AUTOSAR" or MISRA,  etc.

[unsigned_char_array]

---

@Pavel A. wrote:

> There is no such thing as a perfect tool.

The perfect tool is the AI coding assistant, these days. You just give it good instructions and it will write the code, and make sure that no pin is left out.

For example: "Create a function to re-initialize every GPIO pin of the MCU as specified below.

---

Does the AI tool read the datasheet and every errata sheet?