cancel
Showing results for 
Search instead for 
Did you mean: 

Installing STM32CubeProgrammer on Raspberry Pi

Ah.1
Associate II

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.

40 REPLIES 40
DTran.4
Associate

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.

Yes, but openocd does not support external flash loader 'stldr', so for more complex projects you can not take full advantage of stlink.

At least for QSPI- and OctoSPI-attached external flash there is no need for any external flash loader, as OpenOCD has an appropiate driver "stmqspi" already built in.

MJawo.2
Associate II

I'm waiting for STM32CubeProgrammer for ARM too.

I can run full stm32ide on my MAC M2 (but I guess it may be simulated x86 64 bit). However it works and its snappier than my i7 NUC

still waiting 

hit me up in https://www.linkedin.com/in/javiermu%C3%B1oz/

Got it to work with stlink-tools and st-flash


@fghoussen wrote:

Got it to work with stlink-tools and st-flash


For the benefit of other readers, can you give more details of that?

Are these the tools:

https://packages.debian.org/sid/electronics/stlink-tools

https://man.archlinux.org/man/extra/stlink/st-flash.1.en

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

I had no time yet to test with more complex app, but I got a minimal blinky app (using embedded LED) to be flashed OK from RPi and to run OK (change sleep time when building works as expected) on the STM chip connected to the RPi.

Here is how I did if this may help other readers:

>> sudo apt update

>> sudo apt install openocd

>> sudo apt install stlink-tools

>> sudo usermod -aG plugdev $USER # Allow the user to flash. Must be done once + logout / login.

>> lsusb | grep ST-LINK # Plug the USB cable that is connected to the STM: check the STM is seen.

Bus 001 Device 003: ID 0483:374b STMicroelectronics ST-LINK/V2.1

>> st-flash --connect-under-reset write build/zephyr/zephyr.bin 0x08000000

You need to make sure (from the datasheet) that 0x08000000 is the correct address associated to the bank of your chip.

HTH