stm32duino in Arduino on Raspberry Pi

Question

stm32duino in Arduino on Raspberry Pi

odo2063 opened this issue 5 years ago · 54 comments

odo2063 commented 5 years ago

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.

Answer 1 · 2019-10-18T05:43:45.000Z

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.

Answer 2 · 2019-10-18T11:06:03.000Z

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

Answer 3 · 2019-10-18T12:35:45.000Z

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.

Answer 4 · 2019-10-21T07:30:26.000Z

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

Answer 5 · 2019-10-21T07:34:48.000Z

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

Answer 6 · 2019-10-21T07:49:14.000Z

./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...

Answer 7 · 2019-10-21T07:49:53.000Z

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.

Answer 8 · 2019-12-01T19:34:37.000Z

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.

Answer 9 · 2019-12-02T06:46:02.000Z

@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.

Answer 10 · 2019-12-02T12:58:49.000Z

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?

Answer 11 · 2019-12-02T13:21:55.000Z

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

Answer 12 · 2019-12-04T18:54:38.000Z

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

Answer 13 · 2019-12-05T08:02:43.000Z

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

Answer 14 · 2019-12-05T15:25:52.000Z

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.

Answer 15 · 2019-12-06T13:02:26.000Z

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?

Answer 16 · 2019-12-06T13:29:29.000Z

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?

Answer 17 · 2019-12-07T10:56:07.000Z

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

Answer 18 · 2019-12-08T06:42:57.000Z

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

Answer 19 · 2019-12-08T10:02:12.000Z

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?

Answer 20 · 2019-12-08T20:07:03.000Z

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.

Answer 21 · 2019-12-08T22:07:08.000Z

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?

Answer 22 · 2019-12-08T22:36:29.000Z

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...

Answer 23 · 2019-12-09T07:43:26.000Z

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

Answer 24 · 2019-12-09T08:46:40.000Z

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.

Answer 25 · 2019-12-09T09:42:35.000Z

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.

Answer 26 · 2020-05-21T11:13:36.000Z

i just tried to install STM32 Cores 1.9.0 on my Raspberry Pi
(newest Raspbian Buster updated and upgrades and Arduino IDE 1.8.12).

but i get the error message Tool STM32Toolsis not available for your operating system.

does it mean that there is still no support for STM32 on a Raspbian Pi or am i missing something?

ESP32 and Digispark support i could add sucessfully to Arduino IDE on my RPi.
ir would be nice to have STM32 as well.

Answer 27 · 2020-05-21T12:36:08.000Z

On Thu, 21 May 2020 04:13:49 -0700 beta-tester ***@***.***> wrote: i just tried to install STM32 Cores 1.9.0 on my Raspberry Pi (newest Raspbian Buster updated and upgrades and Arduino IDE 1.8.12). but i get the error message `Tool STM32Toolsis not available for your operating system.` does it mean that there is still no support for STM32 on a Raspbian Pi or am i missing something? ESP32 and Digispark support i could add sucessfully to Arduino IDE on my RPi. ir would be nice to have STM32 as well.

I've just updated. Maybe you tried to install just when I was updating the git? koen

Answer 28 · 2020-05-21T15:03:13.000Z

i deleted every stm related stuff from my RPi and re-tried the process:

in Arduino IDE i added the link to the package json file:
and then tried to install the STM32 Cores:

but the installation does not go on, because of the message:
Tool xpack-arm-none-eabi-gcc is not available for your operation system.
(the message now is different to the previous one - maybe i messed too much around previously)

do i have to compile something before i can continue installation?

Answer 29 · 2020-05-21T15:21:01.000Z

i think i got it... i took the regular link for package json
(https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json).

when i take the raspberry pi specific link
/https://raw.githubusercontent.com/koendv/stm32duino-raspberrypi/master/BoardManagerFiles/package_stm_index.json)
the installation succeeds.

Answer 30 · 2020-05-21T16:11:59.000Z

On Thu, 21 May 2020 08:21:16 -0700 beta-tester ***@***.***> wrote: i think i got it... i took the regular link for package json (`https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json`). when i take the raspberry pi specific link /`https://raw.githubusercontent.com/koendv/stm32duino-raspberrypi/master/BoardManagerFiles/package_stm_index.json`) the installation succeeds.

OK. Good. koen

Answer 31 · 2020-08-20T21:44:11.000Z

I've been experimenting with the arduino-cli (Arduino command line tool) on the Raspberry Pi, seems OK to build ATMEL SAMD Arduino programs.

Has anyone tried that approach? Also gcc-arm-none-eabi is a available in the the Buster repo... Works great with
Piconomixs FW

I was able to build the large Piconomixs "cli-explorer" app on a tiny 256 mb of ram, Raspberry Pi 1!

Took a while, but compiled perfectly.

Answer 32 · 2020-09-27T09:38:55.000Z

@RandoSY I was testing arduino-cli on Raspberry Pi 3 model B and had some issue with insufficient memory during installation of stm32duino. But that has been fixed with arduino/arduino-cli#975 (in case you wanted to test it on your Raspberry Pi 1 and see if you can give them feedback about the fix on your Raspi?)

I don't have Raspberry Pi 1, but I am gonna try to do it on Raspberry Pi Zero W

Answer 33 · 2020-10-12T23:22:50.000Z

but the installation does not go on, because of the message:
Tool xpack-arm-none-eabi-gcc is not available for your operation system.

There must be something wrong in your configurations, since the arm-none-eabi-gcc xPack is available on most platforms.

Answer 34 · 2020-10-12T23:26:37.000Z

BTW, any progress with stm32duino on Arm platforms? You no longer have the excuse of the missing toolchain, the Arm versions are available for several months already.

Not to mention that Eclipse Embedded CDT is also available for Aarch64 for some time.

Answer 35 · 2020-10-13T07:17:27.000Z

Currently the toolchain for arm is not provided but will be for the 2.0.0.
The ARM support will be added don't worry but this required some update on tools part which required some time and tests. Moreover I'm busy on other task.
So, this will come be patient. 😉

Answer 36 · 2020-10-13T07:32:33.000Z

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?

Answer 37 · 2020-10-13T07:35:32.000Z

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.

Answer 38 · 2020-10-15T06:27:42.000Z

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

Answer 39 · 2020-10-15T07:25:54.000Z

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?

Answer 40 · 2020-10-15T07:41:36.000Z

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.

Answer 41 · 2020-10-15T08:05:51.000Z

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?

Answer 42 · 2020-10-15T13:52:07.000Z

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

Answer 43 · 2020-10-15T13:57:44.000Z

Great, thank you.

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

Answer 44 · 2020-10-15T14:01:04.000Z

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

Answer 45 · 2021-03-14T20:49:50.000Z

@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....

Answer 46 · 2021-03-15T06:34:49.000Z

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

Answer 47 · 2021-03-15T08:14:44.000Z

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.

Answer 48 · 2021-03-15T17:54:48.000Z

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.

Answer 49 · 2021-05-21T07:40:14.000Z

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.

Answer 50 · 2021-05-21T07:43:51.000Z

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

Answer 51 · 2021-07-28T15:03:49.000Z

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!

Answer 52 · 2021-07-28T17:19:32.000Z

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

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

Answer 53 · 2022-07-25T00:35:07.000Z

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.

Answer 54 · 2022-07-25T07:45:14.000Z

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