stm32duino in Arduino on Raspberry Pi

[odo2063]

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

Describe the solution you'd like
Being able to install stm32duino in Arduino on Raspberry Pi.

Describe alternatives you've considered
none

Additional context
It would be nice to be able to compile and flash stm32duino boards from a Raspberry Pi. At the moment we doing a longterm test where all devices are only available by wifi or GSM. So it would be nice to be able to implement improvements in field. It would also great in schools. the raspi4 is powerful enough to be cheap desktop for schoolusage and then it would be nice if your boards could be used besides it.

[fpistm]

Hi @odo2063,
As I do not have a Raspberry, I will not be able to work on this stuff.
I guess the main works is to have an arm-none-eabi-gcc toolchain for this target and also check all tools used by the core for upload.

If anyone want contribute to this this will be greatly appreciated.

[odo2063]

the arm-none-eabi-gcc seems easy...
https://packages.debian.org/buster/gcc-arm-none-eabi

What else do you need?

i could also give you SSH to Raspi if you like...or you find something with https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/legacy-mpus/spear-arm-cortex-a9-microprocessors.html

[fpistm]

Thanks but I will not have access with SSH due to security policies.
About arm-none-eabi-gcc this require several investigations:

• Which one have to be used depending of the host arch? Honestly, I don't know Raspi ecosystem, what I know is Arduino seems able to handle twice of them (arm64 and armhf)
• arm64
• armel
• armhf
• Which options has been used to build ? (libraries provided? lto support?....), moreover this is not the same version and unfortunately I don't think Arduino IDE was able to deal with as we are able to only reference one.
• Test if all options used is well supported
• Need to be repackage to be installed thanks Arduino but I'm not be able to test.
• ...

What else do you need?

All tools (binaries and scripts) tested and updated in the https://github.com/stm32duino/Arduino_Tools repo.

[odo2063]

Hi I found this one
https://github.com/vanbwodonk/gcc-arm-embedded-build-armhf

[odo2063]

Which one have to be used depending of the host arch? Honestly, I don't know Raspi ecosystem, what I know is Arduino seems able to handle twice of them (arm64 and armhf)

For now consider Raspian as standard Debian on armhf....this will maybe change to arm64 for the Raspi4 in the future

[odo2063]

./dfu-util --version
dfu-util 0.8

...seems to compile

I can run any script you want me to...but I am a newbie when it comes to build up a toolchain with my own hands...

[fpistm]

Currently, I've no time frame to investigate this at least until next year.
If anyone wants try to work on this will be welcome.

[koendv]

Just FYI:
Raspberry already has the following debian packages:

• binutils-arm-none-eabi
• gcc-arm-none-eabi
• libnewlib-arm-none-eabi libnewlib-dev
• libstdc++-arm-none-eabi-newlib

After installing these packages, you can compile stm32 code on Raspberry. Eg. you can compile this: gdb debugger for blue pill. I've added a list of available commands and the output of arm-none-eabi-g++ -v: gcc-output.txt

What's missing (I think) is the STM32 arduino libraries and their headers in the arduino IDE.
HTH.

[fpistm]

@koendv
the main issue is to have n all in one toolchain package (aligned with the gcc version used by other host OS) and as I said I could not test it. So I could integrate it if someone is able to provide and test it.

[koendv]

Fine. If you provide a STM32 board package that assumes arm-none-eabi-g++, arm-none-eabi-ld, dfu-util, ... are in /usr/bin, I can try to compile some examples ("blink") on raspberry and get the examples running on black pill/blue pill. OK?

[fpistm]

When I said "integrate", I mean store it on GitHub and reference it in the boards JSON files.
Not provide it.

[koendv]

OK. odo2063, if I put an arm-none-eabi toolchain up, are you willing to test it?

[odo2063]

I could give you SSH to a raspi if you like...with X-Forwarding...

[koendv]

OK. Your turn. https://github.com/koendv/stm32duino-raspberrypi

gcc-arm-none-eabi-9-2019-q4-major, dfu-util 0.9, hid-flash 2.2.1, built for armv7l-linux-gnu (raspberry in 32-bit mode). Build takes 16.5 hours. I could recompile this for aarch64 if needed.

[odo2063]

I'll compile it that weekend...can we meet at IRC or something like that so I can hand you over the login credentials, because I don't know what to do any further?

[koendv]

OK. I've got a raspberry, I've already compiled the toolchain, and you can download toolchain and stm32tools for 32-bit raspbian "Buster" from my github. What comes next is installing toolchain in the arduino ide.

If I look at the package_stm_index.json file, there are 4 things needed for a functioning toolchain.

• "STM32 Cores 1.7.0"
  can be used mostly as-is. Maybe need to edit platforms.txt because compiler version changed.
• "arm-none-eabi-gcc"
  Already compiled for raspberry. Download from my github. Probably need to change the name of the top-level directory so the naming convention stays the same.
• "STM32Tools"
  Already compiled for raspberry. Download from my github.
• "CMSIS"
  no changes needed.

There are some issues here: it seems arduino packages need to be signed before they can be installed. And because I've compiled arm-none-eabi-gcc-9.2.1 you'll probably need to change "8.2.1-1.7" in platforms.txt to "9.2.1". But, summarizing: it's no longer a problem of compiling, it's a problem of packaging and installing. Perhaps it would be best if some small .json package index file were created for the arm/raspberry platform, for testing.

I will try to compile toolchain and tools for aarch64 this weekend, so we don't have to go through this again when raspbian goes 64-bit.

Does this seem logical to you?

[odo2063]

i got a raspi4 ;-) and if this goes productive we could do a crosscompile...

[fpistm]

You can use the platform.local.txt to override some config.
About the toolchain, thanks the help of @ilg-ul, I moved to 9.2.1. He is currently thinking to provide an toolchain for arm host, see #708

[koendv]

OK. That is good news. You can download the gcc-arm-none-eabi 9.2.1 toolchain and STM32Tools for armv7l (raspberry pi in 32-bit mode) and aarch64 (raspberry pi in 64-bit mode). There's also build notes. Anything else needed?

[ilg-ul]

I did some research and I learned that the first time arm64 was supported by a major Debian distribution was Debian 9 Stretch (ldd --version -> 2.24), and Ubuntu 16.04 (which unfortunately picked a slightly older ldd --version -> 2.23).

Due to the relative order of the system libraries versions, I would say that binaries built on Debian 9 might fail on Ubuntu 16.

Thus, although personally I'd prefer to base my binaries on Debian distributions, it is safer to go for the oldest, which means that for Arm we'll probably have to use Ubuntu 16.04.

This is in line with the Arm build procedure, which also uses Ubuntu 16.04 for the aarch64 binaries, available starting with 9-2019-q4-major.

And, for consistency reasons, I'd use the same 16.04 for both 32 and 64-bit variants (armhf and aarch64).

Any comments on this?

For the moment I installed an Ubuntu 16.04 arm64 on QEMU and I'll use it to update my xPack build scripts to add support for Arm binaries.

Later on I'll probably need a hardware solution, since I expect the build times to be unbearable long in emulation.

[koendv]

OK. Estimate 2.5 days build time.
I guess the advantage will be the 32-bit build will be the more general armhf, and not the raspberry-specific armv7l.
Does this imply the STM32Tools have to be recompiled under Ubuntu?

[ilg-ul]

I guess the advantage will be the 32-bit build will be the more general armhf, and not the raspberry-specific armv7l.

right

Does this imply the STM32Tools have to be recompiled under Ubuntu?

I know nothing about these tools, but if stm32duino is to run on generic Arm 32-bit machines, i guess they have to be armhf too.

---

The comment about avoiding the raspberry-specific armv7l is a good point and should be a gain if indeed armhf binaries run on all Raspberry Pis, large and small.

But the question has another meaning too, if choosing Ubuntu 16.04, anything with ldd --version older than 2.23 probably will not work. I have no idea if there are such systems, for 64-bit probably not, but for 32-bit there might be, I really have no idea.

On the other side, given that making a build environment based on the old Ubuntu 16 is already difficult, and going even further back in time to Ubuntu 14 is almost 'mission impossible', if there are such very old Arm 32-bit systems not able to run Ubuntu 16 armhf binaries, I'm afraid they'll be collateral damages...

[fpistm]

Does this imply the STM32Tools have to be recompiled under Ubuntu?

I know nothing about these tools, but if stm32duino is to run on generic Arm 32-bit machines, i guess they have to be armhf too.

Yes some binaries will have to be built for the targeted hosts (ex: DFU utils).

But the question has another meaning too, if choosing Ubuntu 16.04, anything with ldd --version older than 2.23 probably will not work. I have no idea if there are such systems, for 64-bit probably not, but for 32-bit there might be, I really have no idea.

On the other side, given that making a build environment based on the old Ubuntu 16 is already difficult, and going even further back in time to Ubuntu 14 is almost 'mission impossible', if there are such very old Arm 32-bit systems not able to run Ubuntu 16 armhf binaries, I'm afraid they'll be collateral damages...

I'm not aware of arm based distribution anyway I guess supporting all possibles arch is not possible.
So, I guess your proposal seems reasonable and aligned with ARM choice to use Ubuntu 16.04

[koendv]

Yes some binaries will have to be built for the targeted hosts (ex: DFU utils).

OK. The latest version of dfu-utils is v0.9. If we have to recompile for armhf, let's compile on the same os used for the toolchain, and let's compile the latest version, so we don't have to revisit the subject for a year or longer.

[ilg-ul]

seems reasonable and aligned with ARM choice to use Ubuntu 16.04

Good, we'll stick to Ubuntu 16.04.6 LTS, ldd --version -> 2.23 for both armhf and aarch64 for now.

Yes some binaries will have to be built for the targeted hosts (ex: DFU utils).

Probably it would be good to build them using the same Ubuntu 16. The binaries do not need to be build necessarily on a Pi, since I'm not sure there is such an old official Ubuntu 16 running on Pi (http://cdimage.ubuntu.com/releases/16.04.6/release/), but can also be build on QEMU; for usual projects the speed should not be a limitation, as it is for toolchains; I'll publish the details of my build environments on a separate page, for those who want to play with it.

[ilg-ul]

Currently the toolchain for arm is not provided but will be for the 2.0.0.

In 2.0.0 please be sure you use the correct 32/64-bit version.
And could you also switch the Windows toolchain to the 64-bit version?

[fpistm]

And could you also switch the Windows toolchain to the 64-bit version?

Well, currently I don't know if it should be switch, unfortunately some user always run on 32 bits version.

[koendv]

ARM support ... required some update on tools part
This sounds as if ST-Link will be available on raspberry?

[ilg-ul]

some user always run on 32 bits version.

Is Arduino for Arm able to differentiate between 32/64-bit systems and install the proper toolchain and tools?

[fpistm]

for Arm able to differentiate between 32/64-bit systems and install the proper toolchain and tools?

Unfortunately not. Only we are on Windows else I would deploy both toolchain 32/64-bit.
I've checked which arm version they provide with the new core based on MBed for the new portenta H7 board and it's a v7 win32. So I guess I will kept win32 release.

[ilg-ul]

Sorry for the misunderstanding, the question was related to Linux Arm, I currently do not have Windows Arm binaries for the toolchain.

So, is the Linux Arm version of Arduino able to differentiate between 32/64-bit systems?

[fpistm]

Sorry read to quickly. yes for ARM host OS this is OK for both system.

[ilg-ul]

Great, thank you.

Please be sure you configure the correct toolchain for 32/64-bit Arm Linux systems, since they're both available.

[fpistm]

Of course:
https://github.com/stm32duino/BoardManagerFiles/blob/dev/STM32/package_stm_index.json#L1253-L1266

[BennehBoy]

@koendv silly question, but I'm guessing that rpi 1 isn't supported by your package file? I get segfaults and illegal instructions so I guess I've got the armv7 versions? I wasn't seriously going to use a pi 1 to develop on, just had one lying about so decided to dust it off....

[koendv]

On Sun, 14 Mar 2021 13:50:03 -0700 Ben Anderson ***@***.***> wrote: @koendv silly question, but I'm guessing that rpi 1 isn't supported by your package file? I get segfaults and illegal instructions so I guess I've got the armv6 versions? I wasn't seriously going to use a pi 1 to develop on, just had one lying about so decided to dust it off....

No, AFAIK you'd have to write the board package for rpi1 yourself. I'd type gcc -v on the rpi, to get the compiler options that were used to build gcc for the rpi1, compare that with the compiler options of the gcc used for the arduino build, and work from there. koen

[BennehBoy]

OK, thought as much. The toolchain does get installed just I guess the embedded logic doesn't make any distinction between rpi1 & 2+ (just 32 & 64 bit). I had to downgrade the JDK to allow Arduino to function, Armv6 was desupported at JDK 9.

[BennehBoy]

Works lovely on an rpi4 - but I did have to rename the maple_upload bash script to maple_upload.sh and also amend line 39 to point to the correct location and filename for dfu-util.

"${DIR}/dfu-util/dfu-util" -d "${usbID}" -a "${altID}" -D "${binfile}" ${dfuse_addr} -R

Works a charm afterward.

[fpistm]

Just FYI, latest release now provides the arm none eabi toolchains for arm host:
https://github.com/stm32duino/BoardManagerFiles/blob/62a6f583bd7a10192f57e7e3afe729a12f73a028/package_stmicroelectronics_index.json#L74-L87

Tools will come later.

[ilg-ul]

Koen also has a build with the new Arduino IDE for AArch64.

[Emeric-dufour]

Hello all,

I have trouble with the combination of Arduno-cli, a raspberry pi 4b and stm32duino.
Installing STM32duino gives "Error during install: tool STMicroelectronics:STM32Tools@2.0.0 not available for the current OS".

Current behavior

Behavior is as shown.

While trying to install core STMicroelectronics:stm32, the packages download proceeds as expected, and all the arm-none-eabi-gcc packages are correctly downloaded.

But the STM32Tools download that follows is leading to an error:
"Error during install: tool STMicroelectronics:STM32Tools@2.0.0 not available for the current OS".

This makes it impossible for me to install stm32duino.

hlfc@hlfc-4:~ $ arduino-cli core install STMicroelectronics:stm32
Downloading packages...
STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 774.28 KiB / 140.30 MiB    STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 1.85 MiB / 140.30 MiB    1.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 3.02 MiB / 140.30 MiB    2.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 4.15 MiB / 140.30 MiB    2.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 4.15 MiB / 140.30 MiB    2.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 4.99 MiB / 140.30 MiB    3.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 6.22 MiB / 140.30 MiB    4.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 7.37 MiB / 140.30 MiB    5.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 8.33 MiB / 140.30 MiB    5.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 8.33 MiB / 140.30 MiB    5.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 9.33 MiB / 140.30 MiB    6.STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 10.46 MiB / 140.30 MiB    7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 11.52 MiB / 140.30 MiB    8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 12.57 MiB / 140.30 MiB    8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 12.57 MiB / 140.30 MiB    8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 13.63 MiB / 140.30 MiB    9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 14.68 MiB / 140.30 MiB   10STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 15.79 MiB / 140.30 MiB   11STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 17.10 MiB / 140.30 MiB   12STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 17.10 MiB / 140.30 MiB   12STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 18.40 MiB / 140.30 MiB   13STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 19.65 MiB / 140.30 MiB   14STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 20.82 MiB / 140.30 MiB   14STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 21.80 MiB / 140.30 MiB   15STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 21.80 MiB / 140.30 MiB   15STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 22.74 MiB / 140.30 MiB   16STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 24.30 MiB / 140.30 MiB   17STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 25.35 MiB / 140.30 MiB   18STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 26.44 MiB / 140.30 MiB   18STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 26.44 MiB / 140.30 MiB   18STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 27.49 MiB / 140.30 MiB   19STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 28.65 MiB / 140.30 MiB   20STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 29.66 MiB / 140.30 MiB   21STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 30.72 MiB / 140.30 MiB   21STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 30.72 MiB / 140.30 MiB   21STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 31.96 MiB / 140.30 MiB   22STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 33.16 MiB / 140.30 MiB   23STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 34.44 MiB / 140.30 MiB   24STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 35.52 MiB / 140.30 MiB   25STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 35.52 MiB / 140.30 MiB   25STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 36.66 MiB / 140.30 MiB   26STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 37.66 MiB / 140.30 MiB   26STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 38.63 MiB / 140.30 MiB   27STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 39.32 MiB / 140.30 MiB   28STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 40.71 MiB / 140.30 MiB   29STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 40.71 MiB / 140.30 MiB   29STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 41.13 MiB / 140.30 MiB   29STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 41.46 MiB / 140.30 MiB   29STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 43.49 MiB / 140.30 MiB   31STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 44.58 MiB / 140.30 MiB   31STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 45.76 MiB / 140.30 MiB   32STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 45.76 MiB / 140.30 MiB   32STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 46.83 MiB / 140.30 MiB   33STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 47.80 MiB / 140.30 MiB   34STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 48.86 MiB / 140.30 MiB   34STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 49.96 MiB / 140.30 MiB   35STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 49.96 MiB / 140.30 MiB   35STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 51.02 MiB / 140.30 MiB   36STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 52.02 MiB / 140.30 MiB   37STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 53.06 MiB / 140.30 MiB   37STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 53.96 MiB / 140.30 MiB   38STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 53.96 MiB / 140.30 MiB   38STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 54.94 MiB / 140.30 MiB   39STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 56.38 MiB / 140.30 MiB   40STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 57.59 MiB / 140.30 MiB   41STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 58.86 MiB / 140.30 MiB   41STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 58.86 MiB / 140.30 MiB   41STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 59.83 MiB / 140.30 MiB   42STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 61.09 MiB / 140.30 MiB   43STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 62.30 MiB / 140.30 MiB   44STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 63.39 MiB / 140.30 MiB   45STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 63.39 MiB / 140.30 MiB   45STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 64.60 MiB / 140.30 MiB   46STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 65.81 MiB / 140.30 MiB   46STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 67.04 MiB / 140.30 MiB   47STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 68.29 MiB / 140.30 MiB   48STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 69.32 MiB / 140.30 MiB   49STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 69.32 MiB / 140.30 MiB   49STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.31 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 70.90 MiB / 140.30 MiB   50STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 75.63 MiB / 140.30 MiB   53STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 76.94 MiB / 140.30 MiB   54STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 78.02 MiB / 140.30 MiB   55STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 79.07 MiB / 140.30 MiB   56STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 79.07 MiB / 140.30 MiB   56STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 80.25 MiB / 140.30 MiB   57STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 81.41 MiB / 140.30 MiB   58STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 82.52 MiB / 140.30 MiB   58STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 83.74 MiB / 140.30 MiB   59STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 83.74 MiB / 140.30 MiB   59STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 85.02 MiB / 140.30 MiB   60STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 85.88 MiB / 140.30 MiB   61STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 87.01 MiB / 140.30 MiB   62STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 88.05 MiB / 140.30 MiB   62STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 89.18 MiB / 140.30 MiB   63STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 89.18 MiB / 140.30 MiB   63STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 90.28 MiB / 140.30 MiB   64STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 91.46 MiB / 140.30 MiB   65STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 92.56 MiB / 140.30 MiB   65STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 93.73 MiB / 140.30 MiB   66STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 93.73 MiB / 140.30 MiB   66STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 94.82 MiB / 140.30 MiB   67STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 95.91 MiB / 140.30 MiB   68STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 96.91 MiB / 140.30 MiB   69STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 98.10 MiB / 140.30 MiB   69STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 98.10 MiB / 140.30 MiB   69STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 99.31 MiB / 140.30 MiB   70STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 100.38 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 101.46 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 102.60 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 102.60 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 103.76 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 104.94 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 106.18 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 107.27 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 107.27 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 108.33 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 109.37 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 110.62 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 111.37 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 111.37 MiB / 140.30 MiB   7STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 112.51 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 113.46 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 114.40 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 115.41 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 115.41 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 116.35 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 117.37 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 118.30 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 119.32 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 119.32 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 120.52 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 121.61 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 122.70 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 123.88 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 123.88 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 125.02 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 126.15 MiB / 140.30 MiB   8STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 127.16 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 128.33 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 128.33 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 129.48 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 130.83 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 131.93 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 132.93 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.26 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.26 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 134.47 MiB / 140.30 MiB   9STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 138.97 MiB / 140.30 MiB   9
STMicroelectronics:xpack-arm-none-eabi-gcc@9.3.1-1.3 downloaded                 
Error during install: tool STMicroelectronics:STM32Tools@2.0.0 not available for the current OS

Expected behavior

I would like to be able to download and install the stm32 core properly to be able to compile and upload stm32duino based sketches for the board/mcu I am using (STM32H743) from my Raspberry Pi 4B, using the arduino-cli.

Environment

• CLI version (output of arduino-cli version):

Arduino-cli 0.18.3 on Raspberry Pi 4 model B.
JSON file:
https://github.com/stm32duino/BoardManagerFiles/raw/master/package_stmicroelectronics_index.json

• OS and platform:

hlfc@hlfc-4:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

hlfc@hlfc-4:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

hlfc@hlfc-4:~ $ uname -a
Linux hlfc-4 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux

If somebody has some advice for me, that would be amazing thanks!

[ilg-ul]

xpack-arm-none-eabi-gcc@9.3.1-1.3

BTW, since December 2020 there is also a 10.x toolchain release.

[camelator]

Hi,
not sure to understand the problem... so sorry if my answer is not relevant or stupid:
in my configuration, I am using plateformio with a black magic probe flashed on a STM32F103. By this way, you can use the IDE you like (I am using studiocode), the hardware you like (raspberry, etc...) and the framework you like (STM32 duino, ...). The black magic probe is linked to the hardware by USB and allow debugging.
as far I know, it is working on raspberry.

[fpistm]

Hi @camelator
here we talk about Arduino IDE not PIO.