Unable to flash with STM32CubeProgrammer

[SimonHuwyler]

Hi,

I just installed STM32CubeProgrammer v2.17.0 on Linux.

When I connect to the board (tried with several different ones), I get the following error;

flash loader cannot be loaded. FlashLoaderPath = /home/[yadayada]/bin/FlashLoader/0x

I can read the flash, I can do everything, with the exception of flashing. This fails.

I first thought it might be a truncated log message. But when I just copied any of the loader files and gave it the file name "0x", I didn't get the error message. So it really looks for a file named "0x". It looks like in the code, the assembly of the file name (all the files match the pattern 0x*.stldr)

I tried to do an software update, but this also fails: "The updater package on server is corrupted"

[AMacd.1]

You did not actually answer my question.

Nevertheless, here is the information you requested:

I am using v2.18 - the issue is not fixed.  My OS: Ubuntu 22.04LTS.  Steps:

1. Install cube from ST.COM (en.stm32cubeprg-lin-v2-18-0.zip):

  Note: installation directory is not the home directory.  It is installed in

    /home/username/Data/STMicroelectronics/STM32Cube

  where

    /home/username/Data is a simlink to /media/username/Data

2. Run cube application

3. Plug in stm32f3discovery

4. Press refresh button in ST-LINK Configuration sidebar

5. Observe device serial number.

6. Click "Connect"

Error happens:

5:01:45 : Error: flash loader cannot be loaded. FlashLoaderPath = /media/username/Data/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/FlashLoader/0x

Notice that path is truncated.  The workaround that appears in other postings in this thread and on another site (https://stackoverflow.com/questions/78850472/stm32cubeprogrammer-flash-loader-cannot-be-loaded) seem to be aware of this path truncation.

That's all I am going to contribute to this thread at this time.

[Tesla DeLorean]

Looks to be a Linux side issue, probably with how you're sprintf() formatting the DEV_ID into the filename / path expansion.

[Jyrki Koivisto]

That external flash loader file is just some thumb code that runs inside the micro and programs the EXTERNAL flash if even present. Internal flash is programmed differently.

Look at the Device ID in the bottom right corner under the st-link configuration. I believe that should be the name of the correct external flash programmer.

If you don't need to flash any external memory then it should not matter what you name "0x"

[steveT]

I too have the same issue. I have 2 computers both running Debian 12. Cube Programmer v2.18 is installed in home folder of both.

In my case, computer 1 works fine. Computer 2 does not work. I get the exact same loader error.

Computer 2 that does not work correctly was built from Computer 1 as the entire home drive was copied from Computer 1 to Computer 2 when I built it a few months ago. The System on computer 2 was a fresh install.

In my case, my target CPU is STM32G474.

Computer 2 works if I copy the file 0x469.stldr to file name 0x .

Computer 1 Just works as it should.

I have searched around for any config files but there seem to be none that I can find that are in text format to check for errors in the path.

I have tried uninstall and reinstall of CubeProgrammer but no difference. CubeMX runs fine. I do not use CubeIDE as I use Rowley Crossworks.

[AMacd.1]

I tried several different files selected at random: 0x1E.stldr, 0x32.stldr, 0x44C.stldr 0x433.stldr, and a couple of others.  None of these worked.

[AMacd.1]

However, if I connect the device without renaming anything, and click through the error, then the Device ID will appear bottom right corner, under the heading "Target Information".  In my case, it is "0x422".  So, if I copy the file named "0x422.stldr" and rename the copy "0x" (no extension), disconnect and reconnect, I can program my board.

[steveT]

Exactly same way I got mine to connect.

Same thing Jyrki Koivisto said to do in his post. However, I think you have to have the correct CPU type renamed. Not just any as he said.

Works for now as a work around. Would like to see a fix. More than happy to help check things if ST has anything they would like input on or testing of.

Luckily the project I am working right now only has the same CPU x 3 and no others. But I suspect this will break with a different CPU type involved and would have to go back and forth renaming.