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

[Andrew Neil]

There's a huge volume of posts on here related to problems connecting to the target, so perhaps it would be worth thinking about how to better signpost people to solving these issues?

A key first step is to distinguish whether the problem is in the connection from Host to ST-Link, or from the ST-Link to the target MCU.

[Maxime_BELAVAL]

Hello Andrew, I hope you're doing well, thanks for your feedback.

We are indeed aware of these connection and stability issues. Our dedicated support team is actively working on them, mainly with the help of @Aziz BRIGUI, @Amine_Jridi and @Kouthair, who reproduce and analyze the problems and then relay their findings to our R&D team.

The purpose of this post is to focus on additional pain points that have been reported through various channels, but for which we currently lack sufficient information to reproduce and investigate them properly.

If you have any insights you'd like to share on these topics, we would really appreciate your input in the comments :)

Max

[LCE]

I'd like to have an option for "auto-disconnect" (+ reset) after programming.

Or is that already available?

[Maxime_BELAVAL]

Hello LCE, thank you for your feedback !

Currently, you need to manually click the Connect/Disconnect button next to the programming interface selector :

 

Would adding a checkbox in the GUI, as shown below, meet your needs ? If so, I assume it should also be possible to save it with the other configuration settings.

 

Thanks,

Max

[LCE]

Exactly something like this!

Maybe one more option: "(Hardware) Reset after Disconnect"

[Ozone]

How about making it Open Souce, e.g. by publishing it on a github repro ?
ST could still retain control over its version by managing pull requests.

[Maxime_BELAVAL]

Hello Ozone, thank you for your suggestion. We fully understand the benefits that opening STM32CubeProgrammer could bring in terms of transparency, community contributions, and faster evolution of the tool.

 

However, STM32CubeProgrammer includes software components and algorithms that are covered by third-party licenses and Non-Disclosure Agreements (NDAs). Because of these contractual and IP constraints, we are not in a position to release the source code of STM32CubeProgrammer as open source.

 

That said, we are committed to providing as much openness and flexibility as possible around our ecosystem :

• We publish flash loaders for STM32 devices on GitHub, enabling customers to better understand, customize, and integrate programming support into their own tools and flows : https://github.com/STMicroelectronics/stm32-external-loader. We plan to extend this flash loader support on GitHub.
• STM32CubeProgrammer also provides a command-line interface as well as a C API to facilitate automation, integration, and the development of your own programming solutions. If you require specific improvements in those areas, we can work on them : please do not hesitate to detail your needs.

 

Thanks,

Max

[petestaples]

Hi Max,

Thanks for opening this up. Here's a use case that comes up every day for us:

We manufacture and test hardware with STM32 MCUs for our clients. Our test stations run ARM Linux — and STM32_Programmer_CLI doesn't have a native aarch64 build. So every time we need to flash an STM32 target in production, we're forced to use OpenOCD instead of ST's own tool.

OpenOCD works, but we lose the benefit of CubeProgrammer's built-in MCU database. We recently hit a dual flash bank config issue on an STM32L0 Cat.5 that CubeProgrammer would have handled out of the box.

What we need: a native ARM Linux build of the CLI — no GUI, just headless flash/verify/erase with reliable return codes for test automation.

I know this has been requested before in the context of Raspberry Pi, but our use case is manufacturing — embedded test platforms running ARM Linux at production scale. Here is a link to our existing product and we are in the process of launching our third generation Production Line Tool (PLT) now (also ARM Linux hardware). Happy to discuss further if it helps make the case internally.

Thanks,
Pete

[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 ?

[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 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

[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.