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?

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

[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

[Maxime_BELAVAL]

Thank you for your prompt confirmation and contribution LCE, much appreciated !

Three different resets exist and are supported by STM32CubeProgrammer. This information is highlighted in the https://www.st.com/resource/en/user_manual/um2237-stm32cubeprogrammer-software-description-stmicroelectronics.pdf, section 2.1.4 Target configuration panel, under "Reset mode" :

• Software system reset: resets all STM32 components except the Debug via the Cortex-M application interrupt and reset control register (AIRCR).
• Hardware reset: resets the STM32 device via the nRST pin. The RESET pin of the JTAG connector (pin 15) must be connected to the device reset pin.
• Core reset: resets only the Cortex-M via the AIRCR (*).

Core reset does not exist for Cortex-M33, Cortex-M55 and Cortex-M85

We will review this with the team to determine the most appropriate way to address this.

Thank you for your feedback,

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