Document alternatives to installing STM32CubeProgrammer

[ssokolow]

Is your feature request/improvement related to a problem? Please describe.

I just recently updated to the 1.6.1 core and discovered that STM32CubeProgrammer is now a dependency for all the flashing methods that I have on hand.

As I'm rather particular about depending on closed-source software, that prompted me to downgrade the core until I can find a suitable alternative. (such as renewing my efforts to find/build a programming harness that'll fit the tiny holes on the Chinese STLink-V2s so I can reflash one of mine to a BMP.)

Describe the solution you'd like

As I don't expect you to re-add support for legacy flashing methods, please consider providing a wiki page that steps Linux users through flashing a supported bootloader onto an STM32 using only open-source software to avoid the need to install STM32CubeProgrammer.

(I remember there used to be something like this on the old wiki.stm32duino.com site, but I'm having trouble finding it if it's been migrated to the GitHub wiki. If it is still there, maybe link it from the "Getting Started" and "Upload methods" pages in the wiki.)

Describe alternatives you've considered

• Documentation on how to build a Docker container that can provide sufficient confidence that an archived copy of STM32CubeProgrammer will still be usable on a Linux device from 30 years in the future which may not have recognizable USB anymore and may have a CPU based on ARM, RISC-V, or something not yet developed. (I don't think I need to go into more detail on why this is "killing a fly with a nuke"-level silly.)
• Documentation on how to build a programming harness that fits the tiny programming points on Chinese STLink-V2 clones so they can be reflashed with BMP using only open-source software. (While it's something I'd also like to know, it'd be better to stick to a solution that doesn't impose additional hardware requirements.)
• Abandoning STM32duino and only developing software for my STM32 boards using the Rust HAL, which programs via OpenOCD. (Pro: better compile-time checks. Con: USB support is fragmented, immature, and with limited features. If I'm not using the USB, I'll probably spec for either an ESP8266 (same price) or STM8 (cheaper) dev board instead or experiment with being an early adopter for Rust on the ESP32.)

[fpistm]

Hi @ssokolow

I will add a link to install the STM32CubeProgrammer in the Getting Started. As described in the PR introducing the tool, choice has been made to replace "legacy" tools as they are not able to support all series moreover was a pain to provide binaries for each host OS.
STM32CubeProgrammer supports all series and are available for all supported host OS.
Install it one time is not a big pain to support all possible upload methods.
You can customize your environment to customize the core (including tools thanks platform.local.txt and boards.local.txt):
https://github.com/stm32duino/wiki/wiki/Custom-board-based-on-a-core

providing a wiki page that steps Linux users through flashing a supported bootloader onto an STM32 using only open-source software to avoid the need to install STM32CubeProgrammer.

This is mainly up to user to know this, I could not document all possible way to flash a bootloader.
Wiki is open, any contribution are welcome. IIRW the wiki done by roger described it unfortunately the wiki is now down and this is not related to ST.

* Documentation on how to build a Docker container that can provide sufficient confidence that an archived copy of STM32CubeProgrammer will still be usable on a Linux device from 30 years in the future which may not have recognizable USB anymore and may have a CPU based on ARM, RISC-V, or something not yet developed. (I don't think I need to go into more detail on why this is "killing a fly with a nuke"-level silly.)

Unfortunately, I'm not able to guarantee that. I'm not responsible of the STM32CubeProgrammer.
As said you can customize your environment to customize the core:
https://github.com/stm32duino/wiki/wiki/Custom-board-based-on-a-core

* Documentation on how to build a programming harness that fits the tiny programming points on Chinese STLink-V2 clones so they can be reflashed with BMP using only open-source software. (While it's something I'd also like to know, it'd be better to stick to a solution that doesn't impose additional hardware requirements.)

Unfortunately, this is not in our scope, if you want to document this this will be welcome.

* Abandoning STM32duino and only developing software for my STM32 boards [using the Rust HAL](https://github.com/TeXitoi/blue-pill-quickstart), which programs via OpenOCD. (Pro: better compile-time checks. Con: USB support is [fragmented](https://github.com/rust-embedded/wg/issues/40), immature, and with limited features. If I'm not using the USB, I'll probably spec for either an ESP8266 (same price) or STM8 (cheaper) dev board instead or experiment with being an early adopter for Rust on the ESP32.)

As you can imagine it is hard to support everyone and provide all that they expect. Up to you to use this core or not and/or contribute. I do my best to fit all requests but could not make all...

[ssokolow]

This is mainly up to user to know this, I could not document all possible way to flash a bootloader.

I never asked for all the ways... just a single one which doesn't require closed-source software to accomplish and will provide "For board X, set the jumpers to position Y, then use compiled image Z" instructions that will be kept up to date if the repo gets shuffled around.

Heck, as-is, you don't seem to have even one set of simple instructions for flashing a bootloader, STM32CubeProgrammer or otherwise.

The closest thing I could find was the instructions for STM32_HID_Bootloader, and it took a less-than-ideal number of steps to find my way from Getting Started to those.

(Something I don't mind remedying if you'll explain the ground rules for what constitute acceptable modifications to the wiki. For example, how "supported" are the various options and how much prominence is allowed for mentions of each level of supportedness from the Getting Started page?)

IIRW the wiki done by roger described it unfortunately the wiki is now down and this is not related to ST.

I think I have that page Ctrl+S saved and possibly one or two other people's "getting started" blog posts, which I could write a new wiki page based on if you can provide the necessary information.

(eg. The path to the bootloader to be flashed for each supported board, documentation on which jumpers to change, etc. I only have the $2-3 basic Blue Pills and Black Pills but, if you can provide instructions that I can confirm to work for Blue Pills, I can at least mark up a reference table based ib provided information.)

Speaking of which, what did happen to that wiki? Do you have any idea?

Unfortunately, I'm not able to guarantee that. I'm not responsible of the STM32CubeProgrammer.

I was just being honest when the form prompted me to list the alternatives I'd considered and getting a little flippant about how unsuited for purpose something like STM32CubeProgrammer is for people whose main reason for wanting open-source toolchains is to ensure that they can use them with arbitrary host machines.

(eg. I own an OpenPandora, which is a 600MHz ARMv7 palmtop PC running an Xfce-based Linux desktop rather than Android. To the best of my knowledge, the only closed-source stuff which supports that odd combination is stuff where members of the community actively solicited builds from the developers.)

Unfortunately, this is not in our scope, if you want to document this this will be welcome.

I would... but I have no idea how. The only blog post I found which detailed how they clipped onto those ultra-tiny programming points was using really tiny Hewlett Packard-branded IC clips that I wouldn't know how to acquire and which may be expensive. Just assuming you'll figure it out is the norm. (Judging by this one, because some of the PCBs had bigger points that were easier to connect to.)

...not to mention that, if you don't have one that happened to use a 128K part programmed to claim 64K, it's necessary to pref off some target support to get it to fit and not everybody mentions that.

On a related note, what's the policy on linking to other people's blog posts? For example, once I have a moment to try them out, could I put together a quick little summary of how to reflash a Blue Pill into a BMP and then provide half a dozen links to various blog posts in case someone finds my instructions obtuse in some way?

Also, I notice that the BMP wiki mentions that it can run on the host PC and bit-bang an FTDI USB-Serial adapter. Do you have any idea whether Arduino_Core_STM32's BMP option would be compatible with this?

As you can imagine it is hard to support everyone and provide all that they expect. Up to you to use this core or not and/or contribute. I do my best to fit all requests but could not make all...

Again, I was just being honest and thorough about the alternatives I considered when prompted.

[fpistm]

Well, several alternatives were brought for legacy or advanced users who want use it and know how.
For example I never used BMP upload method so I could not help on this topic.
I will try to get a backup of the stm32duino wiki hosted by Roger.
And unfortunately, it is hard to support all host OS and hardware. The fact is the legacy upload binaries used (ex: texane STLink does not support all STM32 series and I guess this is not yet as they search new maintainers, they do a really great work and from my personal view was better than older STlink tools)

[fpistm]

Unfortunately, I will not be able to get backup of wiki.stm32duino.
I've updated the wiki getting started page to install the STM32CubeProgrammer tools.
https://github.com/stm32duino/wiki/wiki/Getting-Started#extra-step

[ssokolow]

Was that for technical or inter-personal reasons? Because I saved a bunch of the pages as I read them and it looks like a bunch more are on the Wayback Machine.

[fpistm]

I do not own the old wiki so for legal reason mainly GPDR this could not be done.
Wiki of the stm32duino GitHub organization is open so it can be completed with any relevant information.

[ssokolow]

In other words, inter-personal reasons. Fair enough.

I may try rewriting the relevant bits of the old wiki into the new one as I need them.

[cdrose]

I don't know if this helps but another approach is to fetch the compiled sketch from C:\Users\App Data\Local\Temp (or wherever it goes on your platform) and then just flash the bin directly using ST-Link utility or the command line tool that used to be used via the Arduino environment. You could probably write a script to automate it if you wanted.

[fpistm]

There is already a script provided with the Tools packages and this is transparent for user.
The only thing to do once is to install STM32CubeProgrammer.
If it not install the script warn the user, unfortunately several user do not read the log...

[ssokolow]

@fpistm And others, like me, bought STM32 hardware specifically because, aside from being a good value, at the time, STM32duino didn't require any closed-source flashing tools.

(Hence my decision that, once I'm not coughing my lungs out, I'm going to try flashing one of my Chinese ST-Links into a Black Magic Probe since that option for flashing appears to still be supported.)

You replying to cdrose's suggestion with that comment implies that you don't understand that.

[fpistm]

OK, probably I do not understand your means.

[ssokolow]

What's not to understand? STM32CubeProgrammer is distributed as a pre-compiled binary under a restrictive license that not only forbids reverse-engineering, but forbids you from something along the lines of "allowing this to become open-source".

Looking at the site for it, it appears to be in Java, but, even if a big, heavy blob of "Arduino IDE and STM32CubeProgrammer" Java would run nicely in the constrained memory and CPU of the cheap Raspberry Pi Zero that I want to use for flashing and debugging projects to protect my expensive hardware from mistakes causing shorts, my experience with Java has told me that stuff like raw USB I/O tends to require compiled JNI bits which wouldn't have an ARM version. (Which would mean I'd need to run them under qemu-user emulation, which would drop the performance to 1/10th of the already low Java performance on a Pi Zero.)

With the old approach, I could use the same flasher for both the easy Arduino IDE stuff on my desktop and the safety-flashing on a Pi Zero.

[fpistm]

Ok. So up to you to customize. See https://github.com/stm32duino/wiki/wiki/Custom-board-based-on-a-core. You will find example to use other tools. It is also documented on Arduino website.

[ssokolow]

Ahh. That may actually be better, since I could set it up to flash over an SSH connection to the potentially sacrificial Pi Zero for maximum convenience.