Associate

Solved

Installing STM32CubeProgrammer on Raspberry Pi

Forum|Forum|6 years ago
January 30, 2020
19 replies
16254 views

We've been succesfully using stm32flash in the past to flash our STM32 MCU that are attached to Raspberry Pi servers (no desktop or X). As we moved on to STM32G0 it seems that stm32flash is no longer working and we are forced to use STM32CubeProg to flash our firmware.

Is it possible to install STM32CubeProg on a) ARM such as RPI, b) server with no desktop?

To begin with, the installation instructions require the installation of OpenJFX which is not relevant (nor possible, in lieu of X) in this case, we intend to use only the CLI interface through scripts that perform the flashing.

Then, trying to run the installation script on the RPI fails since the provided installation binary is for x86.

Best answer by Houda GHABRI

Hi ,

It is not possible for the moment to install STM32CubeProgrammer on ARM processor.

There is plan to do it but unfortunately not in the near future.

regards,

Houda

Show previous replies

RMora.4

Associate III

Another alternative to flashing STM32 from the Raspberry Pi over USB is by using JLink Software (JLinkExe docs). Since I work with other microcontrollers this works for me + JLink has ARM builds for most their software. I did this with my NUCLEO-L4R5ZI.

1. First reflash the st-link firmware to jlink firmware. Steps here.

2. Install JLink Software and Documentation Pack to the raspberry pi. This includes JLinkExe. You should then be able to run JLinkExe from command line. If not, you can create the symbolic links in /usr/bin from the install location, /opt for me.

3. Connect STM32 to Raspberry Pi and run JLinkExe.

4. Some of the commands you run from here require device name. You can find your ST device from list of supported ST devices.

5. From here you can flash with 'loadfile' command, erase flash with 'erase', or reset with 'r'.

This got me to a good start with flashing/erasing the board - beyond this I would reference the JLinkExe docs.

Sam Ho

Associate II

Hi Everyone,

any updates on this, really want to be able to run STM32 Programmer CLI on a raspberry pi!!!

Thanks

Sam

JKo

Associate III

More than 2 years on with no progress.

Let's vote on this so the powers that be at ST may actually take this more seriously and do something about it.

https://community.st.com/s/idea/0873W000000fxozQAA/detail

Is it so complicated to cross compile this for ARM?

I'll even do the work if it means signing an NDA to obtain the source to build it myself.

Ah.1Author

Associate

I cannot vote for this suggestion without understanding what are the prerequisites for STM32_Programmer_CLI as it is not open source. Anyhow, my vote was done already in a much simpler way - since I've opened this thread we've removed ST microcontrollers from ALL our designs.

occam25

Associate II

Same here!

Houda GHABRI

ST Employee

Hello dungeonlords789,

For the short/medium term there are no plans to support CubeProgrammer on Raspberry, sorry I don't have a confirmed date when it will be done.

Houda

Ah.1Author

Associate

We no longer use any ST microcontrollers due to your bad practice of abandoning a capability on which we relied in previous versions of our product.

DTran.4

Visitor II

Is it a matter of adding the device ID for STM32G0 to stm32flash? I assume the protocol of the bootloader would be the same? Just a thought.

Rstua.1

Senior

Can not believe this is 2 years old and still no resolution.

Our objective: Field upgrades on units containning STMicro STM32 processors. These units are plugged into user operated equipment which contains a Linux computer. So, yes, it would have been great to have been able to use a form of STM32CUBEPROGRAMMER on a Linux platform.

Our solution? (warning: not for everyone): We added a FAT-formatted / SDCard to every STM32 unit to contain the upgrade STM32 firmware image. Then we wrote a new STM32 program that permanently resides in the STM32 flash to mount and read the SDCard. The STM32 firmware image on the SDCard is then flashed to the STM32's memory.

Why is this not for everyone? Because it necessitates adding an SDCard and socket to the BOM which adds dollars to each and every production unit. We also needed to spend thousands of dollars on developer time to create and test the STM32 upgrade software.