Encountered Error when opening STM32_Programmer_CLI.exe

[dwJavad]

Hi! I'm trying to flash a STM32H723ZG with STM32CubeIDE 1.14.0 and ST-LINK V2

and use OSPI peripheral to communicate with the W25Q256 external flash as QSPI

and I have this error:

(I have tried all the suggestions given in the community to solve this problem, but I still haven't got any results.

The only way I could get the result was using STMcubeIDE version 0.4.

Do you have any suggestion to fix this problem in higher versions? Thank you)

ST-LINK FW : V2J44S7

Board : --

Voltage : 1.58V

JTAG freq : 9000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x483

Revision ID : Rev Z

Device name : STM32H72x/STM32H73x

Flash size : 1 MBytes

Device type : MCU

Device CPU : Cortex-M7

BL Version : 0x93

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a03076.srec

File : ST-LINK_GDB_server_a03076.srec

Size : 195.92 KB

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sector 0

Erasing memory corresponding to segment 1:

Erasing external memory sectors [0 1]

Download in Progress:

Error: failed to download Segment[0]

Error: failed to download the File

Encountered Error when opening C:\ST\STM32CubeIDE_1.14.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.100.202311100844\tools\bin\STM32_Programmer_CLI.exe

Error in STM32CubeProgrammer

Shutting down...

Exit.

[Pavel A.]

Unfortunately you have unsupported Windows version (windows 7). Unsupported means er... no support.

The issue can be resolved by updating your PC to a supported Windows or Linux version or replacing the PC.

[Sbag]

{Unfortunately you have unsupported Windows version (windows 7). Unsupported means er... no support.

The issue can be resolved by updating your PC to a supported Windows or Linux version or replacing the PC.]

That is not a logical solution. 

Why is Stm_programmer that comes with the version of STMCubeIDE able to upload the hex file , and also STM-Utility ? 

Windows goes on changing versions very often , and that comes new problems too. Software makers can integrate backward compatibility easily for most systems. ( I am a software engineer and have written many commercial softwares, complete packages ).

[Pavel A.]

Sorry? you wrote "STM32CubeIDE fails with error from STM32_programmer_CLI.exe" so the STM32_Programmer_CLI.exe in CubeIDE plugins directory is good or not?

If STM32_Programmer_CLI from latest CubeProgrammer does run on win7, try to copy it into CubeIDE plugin dir ?

[dwJavad]

thank you

But this is not the final solution.

Because I have designed the hardware part correctly.

[Sbag]

Are you using Windows or other OS ? If it is windows, which version. 

goto that folder and click of that exe. look at the message you get. If my assumption is correct, you should get and api-..........dll error. 

from command prompt you can provide --help tag . it should ennumerate all the command strings. If it does, it is working and correctly installed. problem is elsewhere. But I am sure sure it will give the same dll error. 

In my case the said is installed in may folders. But it access only that is installed in system folder. It is cannot be changed due to system level protection. 

Try it and see what you get. 

I think STM32_Programmer and STM-LINK utility do not use that dll or have proper code to access the existing dll. 

I have also found some version of the dll is simply dummy but ST_programmer_CLI.exe needs some entrypoint that does not exist. This is problem with the ....CLI.exe that comes with the version of STMCubeIDE - problem to be solved by the software engineers of STM. 

[Pavel A.]

The problem is that Microsoft, in their alternative wisdom, decided to change TL;DR  the way how Windows executables specify "well known" system DLLs (user32, kernel32 etc etc) and the "new order" executables no longer run on old OS without crutches. One still can build "old style" executables with Microsoft "WinXP compatible" toolchain or GNU tools.

[Sbag]

This issue has nothing got to do with Microsoft. 

The problem is with STM32_programmer_CLI.exe that is installed by STM32CubeIDE. 

It needs api-ms-win-core-synch-l1-2-0.dll. and is searching for an entry point "CreateEventW" in THAT dll. 

But that dll is empty. Hence the error. 

I checked the dlls that is installed by vscode. 

The funny thing is THIS entry point in the file api-ms-core-synch-l1-1.0.dll 

STM32_programmer_CLI.exe searches for the entry point in the wrong dll. 

The said entry point is in the dll api-ms-win-core-synch-l1-1-0.dll and not in api-ms-win-core-synch-l1-2.0.dll 

That is the issue. STM engineers should look into this and correct the code that ships with the version of some of their earlier versions. They might have corrected this the version meant for windows 10 or 11. 

BTW stopping of support of windows 7 is the business of Microsoft. Windows 7 is the most stable version. They will bring new versions having functionality that most users do not want, but shall force upgradations. That is business. There could be lakhs of computers still using windows 7 out there. I have seen some customers still using windows 95 happily. As a software designer, I have implemented my software to work on both widows 7 and windows 10. Why can't STM do that ? Upgrading windows means upgrading hardware too which is not easy, cost wise and time wise. 

[Pavel A.]

As I wrote these api-ms-win... DLLs are not real. They are facade of so called "API Sets". See here. 

>  As a software designer, I have implemented my software to work on both widows 7 and windows 10. Why can't STM do that ?

More testing and support work, one can guess. This is extra cost.

> Upgrading windows means upgrading hardware too which is not easy, cost wise and time wise. 

True, but overall minimizing the support surface to one-two latest software and hardware versions yields more savings than expenses. All these remaining users with win7 and older do not have enough business power to keep these versions  supported.

[Sbag]

"As I wrote these api-ms-win... DLLs are not real. They are facade of so called "API Sets". See here"

I do agree to that. Still, it even more proves that microsoft has nothing got to do with this problem. All is on STM.

The point is If STMProgrammer and STM-Utility works well , Why can't STMCubeIDE ?

It i only a matter of detecting the Windows version and calling the procedure relevant to that version. This is not a small software after all.

I do understand the business part. STM simply wants to sell their newer flash tools. Unless they stop the old ones from working, they can't do that effectively. Users shall go on using what they have been . Simple , same as microsoft. 

As long as STLink_Utility or STMprogrammer does its job, I am ok. I am also thankful to STM for providing such a fantastic IDE. 

I am under the process of developing couple of commercial products using STM32F030C8T6TR, which seems to be adequate. 

As for the rest ............................

BTW are you an employee of STM or Microsoft ? Just curious.