No programmer present in Linux (linux lite (ubuntu))

[noweare1]

I recently switched over to linux. I installed arduino then installed stm32duino core. I could compile fine but the ide could not find the tool to download the bin file.

I posted on the arduino forum to see if anyone else had this problem but I got no responses. The stm32duino forum is no longer available so I searched the web for answers. I did not find anything that helped.

I ended up finding the script (stm32CubeProg.sh.) that the arduino ide calls to download the bin files.

This script looks for STM32_Programmer.sh if it doesn't find it in your path it looks for it in $HOME/programs/STM32CubeProgrammer/bin. If it doesn't find it an error msg is displayed to the user.

To get the arduino ide to program my st board I had to download the cube programmer (CLI version) and install it so that arduino ide could find it. BTW- there is a bug in the STM32Cube programmer stand alone version such that is will not come up on my linux machine. It is well known on the ST forums.

I have read and re-read the readme files to see if I had missed something during install but since I used the ide to install the core everything would of been taken care of correctly. I did not find any documentation to advise downloading the programming tool as part of the core install.

I do not remember having to go through this when using windows 10. I am now using Linux.

[fpistm]

Hi, this is not an issue. https://github.com/stm32duino/wiki/wiki/Upload-methods#requirement

This is described in the 1.6.0 release of the core.

[noweare1]

IMO this needs higher visibility. Even if you go to wiki it is not displayed. You have to click "show 17 more pages" to know its there. It's an important part of the process and since it is not done automatically is should be more easily found. Another option would be to use the stand alone ST Programmer tool but that is broken on Linux so not an option. Although not "officialy" an issue it will create an issue for users.

[bperrybap]

Why was this closed? This is still a big issue. It is absolute BS that you have install additional s/w to be able to upload to boards in this Arduino platform. No other Arduino platform does this. With all other Arduino platforms you get everything you need from a s/w perspective to be able to get code downloaded into the supported boards when the platform board package is installed.

Further it is ridiculous to write the scripts to hard code the path to the additional tools to be down under the users home directory vs right in the same directory where the stm32CubeProg.sh lives.

[fpistm]

@bperrybap, Please use a correct language.

I could not package the STM32CubeProgrammer. The default path is hardcoded else it uses the PATH environment and there is other upload method available if user does not want install it. And as I said, the DFU utils will be added for all host OS as an alternative, anyway for Serial and STLink there will be no alternative as they simply does not exist to support all STM32 series (old texane STLink and STM32flash)

[bperrybap]

I was wanting to do some testing on a blue pill with this core but I'm dead in the water because of the need for this extra s/w - which can't be installed using the installer.

Why can't the platform at least come with an application to allow using a serial device (like a USB to serial device) without having to install anything else? Roger's maple/stmduino platform provides this so it works right out of the box. You could go get that serial_upload tool from them and include it.

Having to install another piece of s/w and messing your path variable really goes against the Arduino simplicity model. This additional s/w installation tool that requires separate installation creates a barrier to entry. Of the dozen or so Arduino platforms/cores I've used, none of them require this extra step as the platform comes with everything needed to upload code to the board without having to ever manually add any additional s/w or muck with the path variable.

And there some potential issues by creating this extra step and using a gui based installer/tool and a tool that is much more than what is needed to do uploads to boards. For example, in my case the installer requires a version of JAVA that is not available for my linux os so I can't even install the extra software. Unless there is some other way to update the platform to be able to upload a blue pill over a serial port, I"m dead in the water on this platform.

The platform really needs to come with a serial uploader.

If an additional s/w installation is still going to be required, In terms of locations for installing this extra s/w, For Arduino environments, it should be installed under the platform package directory near or in the same place as the stm32CubeProg.sh wrapper script. A location where the stm32CubeProg.sh can find it rather than under the users home directory. Worst case, the installer should let you install it wherever you want, and the stm32CubeProg.sh should be updated to also look for it in the same directory where it lives. This would allow users to install it in the same same directory as the stm32CubeProg.sh script and the script would be able to find it there rather than just hard code a single path or require it to be on the users path.

[bperrybap]

Ok. So since I really need to do some testing on blue pill with this core. I decided to fix the platform to support a standard serial port without having to install any stm32cube s/w. It only took a few minutes. I grabbed Roger's maple/stm32duino serial_upload script and stm32flash utility and added them to the tools/linux directory. I then tweaked the package.txt file to add a new serial port uploader tool I then tweaked boards.txt to add a new upload_method to the GenF1 menu to allow selecting the new uploader.

And it all works as it should. I can now use a FTDI usb to serial port device to upload to a blue pill board without having to install any other s/w.

You guys really need to fix the STM32 platform to include the ability to use a standard serial port without having to install any other software.

[fpistm]

Roger's maple/stmduino platform provides this so it works right out of the box. You could go get that serial_upload tool from them and include it.

And for other series than the STM32F1.... You can't compare a core which manage only 2 series (F1/F4) and one which handle 14. As said there is no tools which are able to manage these upload method for all series except STM32CubeProgrammer.

Of the dozen or so Arduino platforms/cores I've used, none of them require this extra step as the platform comes with everything needed to upload code to the board without having to ever manually add any additional s/w or muck with the path variable.

I know but currently I have no other simple solution which also be easy to maintain. Moreover, I do not know other core which manage this number of MCU nor boards...

In terms of locations for installing this extra s/w, For Arduino environments, it should be installed under the platform package directory near or in the same place as the stm32CubeProg.sh wrapper script. A location where the stm32CubeProg.sh can find it rather than under the users home directory. Worst case, the installer should let you install it wherever you want, and the stm32CubeProg.sh should be updated to also look for it in the same directory where it lives.

No, it should not be installed in the package directory else when you update the core you will have to reinstall it. The user home directory is the default install path, that's why it is used as a first option. Several user do not change it and so works fine. Moreover user can install it where he wants and simply add it to the PATH env. Finally you can also use the platform.local.txt and boards.local.txt to add your custom upload method.

[bperrybap]

The issue of missing/needed s/w tools after installing the platform is an issue that you guys need to resolve. This is a bigger issue than the original subject of this issue.

The platform should come with all the needed s/w to be able to upload to the supported boards without having to install additional s/w and especially without having to muck with a users path variable. No other platform has this issue. The arduino.cc Arduino platform includes MANY boards and several different cores (AVR and SAM) and supports several different upload methods and they don't have this issue.

If the upload s/w can be installed and run from anywhere (I can't tell since I can't run the installer) then you should be able to put it in the package directory tree and include it as part of the package install so that the user doesn't have to install it separately.

If a user ever has to modify his path to make these types of tools work, then the build tools are broken. i.e. the IDE, makefiles etc are not working properly.

It is better to have the upload s/w be part of the package and installed in the package directory when the package is installed so that it always stays in sync with the package since it would be part of the package. The way it is now by having it separate and in the users home directory, things can get out of sync and eventually you may run into a situation where there can be a compatibility issue between the platform and the version of the uploader s/w. This breaks the model of being able to quickly and easily flip between package versions using the IDE boards manager.

[bperrybap]

My simplistic way of thinking is that an Arduino user should be able to use an "arduino" board using only the Arduino IDE. That includes installing a board package, building a sketch image and uploading it to the board. All without having to step outside of the IDE to install additional s/w or muck with his path variable. This platform fails to be able to do that while all the other platforms can.

[fpistm]

The issue of missing/needed s/w tools after installing the platform is an issue that you guys need to resolve.

It is not missing. It is optional. It is not needed. It is optional as there is other upload method available.

No other platform has this issue.

Fine. No other core provide the same number of MCU support in only one AFAIK.

(I can't tell since I can't run the installer)

Unofrtunately, I'm not responsible of this issue. I'm not managing this tools. I'm simply a user. I know some people met issue to install it. This has been forwarded to the tools teams anyway, do not hesitate to open a point on ST community

you should be able to put it in the package directory tree and include it as part of the package install so that the user doesn't have to install it separately.

You can install it to the package directory but as said if you update the tools package then it will probably be removed by Arduino. And if your point is to provide it as a package, I could not due to license issue.

The way it is now by having it separate and in the users home directory, things can get out of sync and eventually you may run into a situation where there can be a compatibility issue between the platform and the version of the uploader s/w. This breaks the model of being able to quickly and easily flip between package versions using the IDE boards manager.

No it is independent.

It is a community project, any contribution are welcome. Feel free to provide a PR with all what you want and ensure to:

• provide tools which support the 14 STM32 series (soon 15) for ll upload methods.
• provide them for all supported host OS

For ref: https://github.com/stm32duino/wiki/wiki/Upload-methods

[fpistm]

This platform fails to be able to do that while all the other platforms can.

It's your opinion. If I were / could do it, I will.

But again I have no easy maintainable solution for this. So, I know it is a "restriction" anyway it solved all the tools compatibility issue across all STM32 series.

[jpmeijers]

The original issue is also occurring for me: no programmers present of Linux.

I have stm32duino v2.1.0 installed on Ubuntu 20.04, Arduino v1.8.13.

When trying to upload I get this error:

Sketch uses 13432 bytes (5%) of program storage space. Maximum is 262144 bytes.
Global variables use 888 bytes (1%) of dynamic memory, leaving 64648 bytes for local variables. Maximum is 65536 bytes.
sh ___REMOVE___/stm32CubeProg.sh 0 /tmp/arduino_build_688077/Blink.ino.bin -g 
sh: 0: Can't open ___REMOVE___/stm32CubeProg.sh
An error occurred while uploading the sketch

STM32 Cube Programmer is installed and available under the $HOME/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/ path.

I've tried with both an STLinkV3 and a Discovery Board with builtin STLink.