Missing /bin/arm-none-eabi-g++ after SAM boards installed on Raspberry Pi 4

[pabolojo]

Bug Report

I am trying to program an STM32F103C8 with the arduino-cli, I have already managed to install the STM32:stm32 core and the arduino:sam core, but have not achieved to compile anything.

Current behavior

Executing

arduino-cli compile -v --fqbn STM32:stm32:GenF1:pnum=BLUEPILL_F103C8,upload_method=hidMethod,xserial=generic,usb=CDCgen,xusb=FS,opt=osstd rtlib=nano Blink/

I get the following output

Using board 'GenF1' from platform in folder: /home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0
Using core 'arduino' from platform in folder: /home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0
/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/extras/prebuild.sh /tmp/arduino-sketch-1B2E2879AB999AB919CDC08891355A98 /home/pi/Desktop/Blink
Detecting libraries used...
/bin/arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb @/tmp/arduino-sketch-1B2E2879AB999AB919CDC08891355A98/sketch/build_opt.h -c -Os -w -std=gnu++14 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -fno-use-cxa-atexit -I/home/pi/Desktop/Blink -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino/avr -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino/stm32 -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino/stm32/LL -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino/stm32/usb -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino/stm32/OpenAMP -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino/stm32/usb/hid -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino/stm32/usb/cdc -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Drivers/STM32F1xx_HAL_Driver/Inc -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Drivers/STM32F1xx_HAL_Driver/Src -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/STM32F1xx -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Middlewares/ST/STM32_USB_Device_Library/Core/Src -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Middlewares/OpenAMP -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Middlewares/OpenAMP/open-amp/lib/include -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Middlewares/OpenAMP/libmetal/lib/include -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Middlewares/OpenAMP/virtual_driver -w -x c++ -E -CC -DSTM32F1xx -DARDUINO=10607 -DARDUINO_BLUEPILL_F103C8 -DARDUINO_ARCH_STM32 "-DBOARD_NAME=\"BLUEPILL_F103C8\"" -DSTM32F103xB -DUSBCON -DUSBD_VID=0 -DUSBD_PID=0 -DHAL_PCD_MODULE_ENABLED -DUSBD_USE_CDC -DHAL_UART_MODULE_ENABLED -DBL_HID -DVECT_TAB_OFFSET=0x800 -I/home/pi/.arduino15/packages/STM32/tools/CMSIS/5.5.1/CMSIS/Core/Include/ -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Drivers/CMSIS/Device/ST/STM32F1xx/Include/ -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/ -I/home/pi/.arduino15/packages/STM32/tools/CMSIS/5.5.1/CMSIS/DSP/Include -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/cores/arduino -I/home/pi/.arduino15/packages/STM32/hardware/stm32/1.9.0/variants/PILL_F103XX /tmp/arduino-sketch-1B2E2879AB999AB919CDC08891355A98/sketch/Blink.ino.cpp -o /dev/null -DARDUINO_LIB_DISCOVERY_PHASE
Error during build: fork/exec /bin/arm-none-eabi-g++: no such file or directory

Expected behavior

This command should compile the Blink example, but, as the output sais, the /bin/arm-none-eabi-g++ does not exist. Looking at the installation of the SAM boards, the arm-none-eabi is not installed under /bin/ but under /home/pi/.arduino15...
Is there a way to change the path where the arduino-cli is looking for the arm-none-eabi-g++ toolchain?

Environment

• CLI version: arduino-cli Version: 0.11.0 Commit: 0296f4d
• OS and platform: Raspbian GNU/Linux 10 (buster) (Debian 10.2) on a Raspberry Pi 4 (4 GB RAM).

[ubidefeo]

hi @pabolojo

I have successfully compiled for Blue Pill even on the Zero using arduino-cli 0.11.
I haven't been able to upload because of an issue with arm_v6 but compilation worked well.

Check out this comment of mine to get a command line you can try
#755 (comment)

[pabolojo]

hi @pabolojo

I have successfully compiled for Blue Pill even on the Zero using arduino-cli 0.11.
I haven't been able to upload because of an issue with arm_v6 but compilation worked well.

Check out this comment of mine to get a command line you can try
#755 (comment)

hi @ubidefeo

I can afford not being able to compile on the raspberry pi 4 directly (it would be great to be able to do so but if its not possible i dont mind), but I need to be able to upload the sketch to the stm32 directly from the pi, if not, I would need to do lots of modifications on the design of my project.

Do you know if there is any way to flash the hex file directly to the stm32 through the HID bootloader of the stm32, using the raspberry pi as host?

I see that you are using the stm32duino:STM32F1 board, but I have installed the "official" STMicroelectronics board core for the STM32 (STM32:stm32), I dont know if other cores are compatible with the HID 2.2 bootloader of the STM32.

[ubidefeo]

@pabolojo

I have quickly tested on Mac and it compiles but will have to investigate the behaviour on Pi 4 to come up with a reason why it fails.
I'll notify you as soon as I give it a shot :)

[ubidefeo]

also a question:
I have the STM32:stm32 core which I installed via Stm32duino.
Where did you get the "official" one?

[pabolojo]

@ubidefeo

It seems that mine is also from Stm32duino, but I saw in your comment that you were compiling with stm32duino:STM32F1:genericSTM32F103C6 board, btw this is the link from the core that I am using:

https://raw.githubusercontent.com/stm32duino/BoardManagerFiles/master/STM32/package_stm_index.json

I have managed to do a work around for my problem, I compile with the compile option and then I flash the .bin to the STM32 directly with the hid-flash program from STM32_HID_bootloader, that worked for me!

[ubidefeo]

@pabolojo
I wasn't in fact aware of another core for STM32, that's why I asked.
I would have fallen victim of my own ignorance :D (and learned something in the process)

I'm happy you sorted that out, but uploading with the -u flag should work in the Arduino CLI once the core parameters for your board are properly set.

As soon as I manage to fire up a Pi 4 I'll test with my Blue Pill, I have two and one should still have the HID bootloader on

[ubidefeo]

@pabolojo
I installed the other STM32 core and was able to compile on Mac, but I got an issue when doing copy/paste of your command above

arduino-cli compile -v --fqbn STM32:stm32:GenF1:pnum=BLUEPILL_F103C8,upload_method=hidMethod,xserial=generic,usb=CDCgen,xusb=FS,opt=osstd rtlib=nano

then I realised the last parameter needed to be added to the --fqbn string and separated by a comma, otherwise it would trigger an issue with the output file name.
Once this was done the compilation worked through but upload does not, which makes me suspect my Blue Pill (Amazon bought) might not have that bootloader. Need further investigation.

Using library SrcWrapper at version 1.0.1 in folder: /Users/ubidefeo/Library/Arduino15/packages/STM32/hardware/stm32/1.9.0/libraries/SrcWrapper
/Users/ubidefeo/Library/Arduino15/packages/STM32/tools/xpack-arm-none-eabi-gcc/9.2.1-1.1/bin/arm-none-eabi-size -A /var/folders/jh/wl2lwl_x55j8c64qkmgl1qxw0000gn/T/arduino-sketch-3DA9B4124669EC9B83DF8146160277B9/BlinkMe.ino.elf
Sketch uses 21080 bytes (32%) of program storage space. Maximum is 65536 bytes.
Global variables use 3804 bytes (18%) of dynamic memory, leaving 16676 bytes for local variables. Maximum is 20480 bytes.
"/Users/ubidefeo/Library/Arduino15/packages/STM32/tools/STM32Tools/1.4.0/tools/macosx/hid-flash" "/Users/ubidefeo/BlinkMe/build/STM32.stm32.GenF1/BlinkMe.ino.bin" {serial.port.file}

+-----------------------------------------------------------------------+
|         HID-Flash v2.2.1 - STM32 HID Bootloader Flash Tool            |
|     (c)      2018 - Bruno Freitas       http://www.brunofreitas.com   |
|     (c) 2018-2019 - Vassilis Serasidis  https://www.serasidis.gr      |
|   Customized for STM32duino ecosystem   https://www.stm32duino.com    |
+-----------------------------------------------------------------------+

> Trying to open the [{serial.port.file}]...
error, counldn't open [/dev/{serial.port.file}]
> Unable to open the [{serial.port.file}]
> Searching for [1209:BEBA] device...
##########
Error - [1209:BEBA] device is not found :(> Searching for [{serial.port.file}] ...
error, counldn't open [/dev/{serial.port.file}]
error, counldn't open [/dev/{serial.port.file}]
error, counldn't open [/dev/{serial.port.file}]
error, counldn't open [/dev/{serial.port.file}]
error, counldn't open [/dev/{serial.port.file}]
> Finish
Error during Upload: uploading error: uploading error: exit status 1

Once I have it running start to end on the Mac I'll move to the Pi 4 :)

[ubidefeo]

@pabolojo
I figured out a few things thanks to the STM32:stm32 core used inside the Arduino IDE, and was able, in the end, to upload via CLI, but a bit of trickery was required.

Now it works every time, though :D

1. You will need the Maple Bootloader 2.0 on your board. Not every Blue Pill comes with a proper one. Having an ST-Link v2 can help. More details here
2. You might need your USB connector's Data Line to be pulled up with a 1K5 resistor (I did it on mine) in order for the USB interface of the STM32 to be recognised. Same link as above, option 2 "Another alternative"
3. The settings for a successful upload in the IDE are as follows. If you make a mistake there you will lose the chance to upload via the bootloader (in the specific USB Support: CDC (generic...)). If everything works out you'll also have a Serial which is used by the script in the core to detect a correct upload by simply "seeing" the port alive
   
4. You will need to double-reset the board very quickly as soon as the upload begins (unless you implement the more advanced circuitry as explained in the article linked above (not worth it on such a cheap piece of hardware)

Once that is all working in the IDE, you can use the following command to upload your
arduino-cli compile -v -b STM32:stm32:GenF1:pnum=BLUEPILL_F103C8,upload_method=dfu2Method,xserial=generic,usb=CDCgen,xusb=FS,opt=osstd,rtlib=nano -p /path_to/cu.usbmodemYOURMAPLESERIAL -u

That allowed me to have the sketch uploaded on Mac.
Now that I know it can work, I'll look into running it on the Pi 4.
Also, @cmaglie suggested that any failure on Pi might be due to a specific tool not available on ARM.
More to follow :)

[ubidefeo]

As @cmaglie guessed, some tools are missing for the Raspian OS.
I ran the core install command using the -v flag and this is part of the output

INFO[0002] Installing tool                               Tool="STM32:[email protected]"
Installing STM32:[email protected]...
WARN[0002] Cannot install tool                           Tool="STM32:[email protected]" error="no compatible version of xpack-arm-none-eabi-gcc tools found for the current os"
INFO[0002] Installing tool                               Tool="STM32:[email protected]"
Installing STM32:[email protected]...
WARN[0002] Cannot install tool                           Tool="STM32:[email protected]" error="no compatible version of STM32Tools tools found for the current os"

This happens using the STM32:stm32 core available via the index at https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
This core implements XPack tools at version 9.2.1 ([email protected]) which is not compatible with the Raspberry Pi. They seem to have released 9.3.1-1.1 which supports the Pi but this is not part of the core yet.
I guess it's a matter of days, but we can give them a nudge, I'll link this comment in an issue over there)

When using the other index (http://dan.drown.org/stm32duino/package_STM32duino_index.json) has a different boards and tools configuration, compilation on the Pi works (as I point out in #755 ), as it doesn't rely on XPack tools but uses [email protected].

I don't have the knowledge to tell you which core is better than the other, so I'll try and drag @facchinm in this for his opinion, but the first index (using XPack) seems to be better organised, but I have no idea what the advantages of XPack tools are.

Let's see if the STM32:stm32 core gets updated soon, but in the meantime just use STM32duino if you want to get your thing going :)

[ilg-ul]

I have no idea what the advantages of xPack tools are

The xPack binaries support more platforms, for one.

There other advantages too (http://xpack.github.io), for example they can be added as dependencies to generic projects.

[ubidefeo]

thank you @ilg-ul
I'll do some reading up on xPack.
For what I've seen at a glance it looks like you're doing a good job ;)

[ilg-ul]

Thank you!

[umbynos]

Since this is not an issue with the cli, but a problem with the core not having a release for linux arm64 I'd close that one.

[ilg-ul]

Just curious, is there support for Raspberry Pi OS in the latest Arduino tools?

[umbynos]

Sorry, could you be a little more specific? What do you mean by "Arduino tools"? If you wanted to ask if the CLI supports raspberry PI OS, yes. We provide binaries for linux arm, you can find more info in the documentation

[ilg-ul]

the CLI supports raspberry PI OS

I'm not familiar with the Arduino tools, I mean everything required for practical work; if arduino-cli is the only one, then it should be fine.

As far as I know, the xPack arm-none-eabi-gcc is used by the IDE version of Arduino for STM32; I'd be interested to know if it also works properly with arduino-cli, on all supported platforms, including RPi OS.

[per1234]

If it works in Arduino IDE, it will also work with Arduino CLI. Arduino CLI just executes whatever command was specified by the STM32duino boards platform, using whatever tool version their package specified for use with the host architecture. So in the case of platform toolchains (vs the Arduino CLI binary and its "built-in" tools serial-monitor, serial-discovery, mdns-discovery, ctags), whether the user is using Arduino IDE or Arduino CLI is irrelevant.

[ilg-ul]

Great, thank you!