Your Voice Matters : Help Us Improve STM32CubeProgrammer Usability & Error Messages

[Maxime_BELAVAL]

Dear STM32CubeProgrammer Community, I hope you are all doing well.

Over the past months, you may have received an email from me, either through the STM32CubeProgrammer survey or on other topics like CSAT or Raspberry Pi support.

First, I would like to thank you a lot for all your contributions and feedback, we highly appreciate them, your voice matters !

We’re currently working on improving STM32CubeProgrammer’s usability and would like to 1. reduce the number of repetitive / low added value actions you have to perform, and 2. provide you with clearer error messages.

We need your contributions to address priority scenarios.

Could you please share in the comments which improvements, use cases, or automated actions you would like to see in the tool to make your daily work easier ?

This includes typical errors you often get that you think the tool could prevent or handle automatically, as well as any “why do I have to do this myself every time?” situation you encounter.

A non-exhaustive list you have already reported :

• x3 OK pop-up when clicking on Start Programming
• Automatic device list refresh (instead of manually pressing “Refresh” most of the time)
• Automatic connection attempt when clicking on "Start Programming"
• Unclear J-Link error messages when attempting to connect to a non-powered STM32 board

Short descriptions are perfectly fine (e.g. “Each time I do X, I always need to manually do Y and Z before it works”), as well as unclear errors you want us to improve (e.g. “I did this, and got this error but I couldn’t understand how to do things right”).

You can either reply directly in this thread or send me a private message.

Thanks a lot in advance for your feedback, I wish you all a nice day,

Max

[MR87]

Hi,

thank you for this post. Recently I post here:

https://community.st.com/t5/stm32cubeprogrammer-mcus/serial-numbering-by-script/td-p/889980

a proposal for a small extension to the Serial Numbering section: allowing the user to provide a script that returns the serial number (SN) to be programmed.

This would be very useful in cases where two or more programming stations need to be synchronized at the serial number level.
The script-approach simplifies implementation for ST, while also giving production engineers the flexibility to integrate their existing backend logic (a shared database, a CSV file, a REST call, etc.) to provide the SN to program.

Thank you,

Matteo

[Maxime_BELAVAL]

Hello Pete, hope you're doing well.

Thank you for sharing your use case in such detail, it’s much appreciated.

A CLI package of STM32CubeProgrammer with Linux ARM 64-bit support will be publicly available soon! We will share more information in the coming weeks, so please stay tuned.

Since we are on the topic of ARM support, a dedicated Windows ARM package is also on our roadmap for next year.

Wishing you a great day,

Max

[Andrew Neil]

---

@Maxime_BELAVAL wrote:

A CLI package of STM32CubeProgrammer with Linux ARM 64-bit support will be publicly available soon!

---

Just 64-bit ?

And just CLI ?

[Maxime_BELAVAL]

Hello Matteo,

Thank you for highlighting this and for sharing your request regarding the automatic mode available in the GUI.

I’ll add more details in your original post so that we can keep this thread focused specifically on the idea of making the automatic mode more flexible, independently of the use case (development, pre‑production, production, etc.).

We are aware that this programming method can be improved (e.g., concerning option bytes configuration).
We would really appreciate your feedback on this feature as a whole.

How would you ideally envision the automatic mode?
Would you find it more convenient to have a single input file containing all programming settings, or would you rather have multiple, more granular input files, each handling specific settings (e.g., one for the serial numbering, one for the option bytes, one for the pre & post programming operations, etc., each optional)?

Thank you, wish you a nice day,

Max

[Maxime_BELAVAL]

Hello Andrew,

Yes, it will be CLI-based and 64‑bit only.
The primary targets are CI/CD and test pipelines, automated programming, and remote programming.

The feedback we have collected from customers has strongly driven us to consider this support, excluding GUI and 32-bit.

Depending on the responses and adoption this package generates, we will prioritize additional features accordingly.
More information will be shared soon.

Wish you a nice day,

Max

[MR87]

Hello Maxime,

thank you for your reply.

From my point of view, would it be more convenient to have a single input file cointaining all programming settings (including the Serial Numbering script reference).

Having a sort of programming "project file" would allow to customize the programming process for a specific product. And in a production context, each product would have its own project file. In this way would also be useful for tracing the programming settings used for a specific product/batch or production version and for maintaining a backup of those settings.

Thank you, have a nice day,

Matteo

[LCE]

I just found that an STM32L0x running at max 32MHz has sometimes problems with SWD at 24 MHz.

Maybe an automatic detection of MCU type and reduction of SWD rate could help?
Like start slow, then increase, or so.

Took me a minute to realize that it was only such an easy to solve problem.

[Maxime_BELAVAL]

Hello Pete, hope you're doing well.

I can now finally respond to your comment thanks to today’s Developer News that we just released: [Coming June 2026] Raspberry Pi support for STM32CubeProgrammer

64-bit Linux Arm support, CLI-only, will officially be available starting with STM32CubeProgrammer release 2.23 in June.

Max

[petestaples]

Hi Matteo,

My company, Blue Clover, is an ST Partner and we make production flashing solutions built around a piece of hardware called a Production Line Tool (PLT) that runs YAML test scripts in one shot that does flashing, provisioning, serial numbers, and test automation. You might keep this in mind. The "test plan" as we call it sounds like your "project file" concept.

-Pete

P.S. more info here: docs.pltcloud.com