2024-04-02 01:43 AM
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.
2024-05-10 10:03 PM
I use the log file to see what is happening in detail
This is the output
STMicroelectronics ST-LINK GDB server. Version 7.7.0
Copyright (c) 2024, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
LogFile Name : C:\Users\user\STM32CubeIDE\workspace_1.15.0\BLINKY\Debug\st-link_gdbserver_log.txt
Logging Level : 31
Listen Port Number : 61236
Status Refresh Delay : 15s
Verbose Mode : Enabled
SWD Debug : Enabled
COM frequency = 950 kHz
Target connection mode: Attach
Reading ROM table for AP 0 @0xe00fffd0
Hardware watchpoint supported by the target
ST-LINK Firmware version : V2J45S7
Device ID: 0x410
PC: 0x1
ST-LINK device status: RUN_MODE
ST-LINK detects target voltage = 3.28 V
ST-LINK device status: RUN_MODE
Stm32Device, pollAndNotify running...
ST-LINK device initialization OK
SwvSrv state change: 0 -> 1
Waiting for debugger connection...
Waiting for connection on port 61236...
Waiting for connection on port 61237...
Accepted connection on port 61236...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 61236...
GDB session thread running
GdbSessionManager, session started: 1
Try halt...
ST-LINK device status: HALT_MODE
Accepted connection on port 61236...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 61236...
GDB session thread running
GdbSessionManager, session started: 2
Enter STM32_SystemReset() function
Enter STM32_InitAfterReset() function
NVIC_DFSR_REG = 0x00000008
NVIC_CFGFSR_REG = 0x00000000
Stm32Device, closeDevice() entry
GDB session, device event: 5
GDB session, device event: 5
Stm32Device, pollAndNotify stopped
Stm32Device, closeDevice() exit
------ Switching to STM32CubeProgrammer -----
Encountered Error when opening C:\Program Files (x86)\STM32CubeIDE_1.15.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.201.202404072231\tools\bin\STM32_Programmer_CLI.exe
------ Switching context -----
Error in STM32CubeProgrammer
GDB session terminated: Client connection lost
GdbSessionManager, session terminated: 1
GDB session terminated: Client connection lost
GdbSessionManager, session terminated: 2
GdbSrv, last session terminated, signal dispose
Stopping port 61236
Received stop for port 61236, not accepting new connections.
GdbSrv, deInit entry.
Shutting down...
GdbSessionManager, deInit entry.
GDB session disposed: 2
GDB session disposed: 1
GdbSessionManager, deInit exit
SwvSrv deInit entry
Stopping port 61237
Stopping port 61236
Received stop for port 61237, not accepting new connections.
SwvSrv deInit exit
Stm32Device, closeDevice() entry
Stm32Device, closeDevice() exit
Stm32Device, deInit success
GdbSrv, deInit exit.
Exit.
The funny thing is I can upload the hex file from STM32CubeIDE using Stm32programmer as well as ST_LINK utility. But not STM32CubeIDE.
So there is no issue with ST-Link V2 (Clone?) or the Bluepill board. So this is definitely the IDE issue.
2024-05-11 09:41 AM
I have had similar problem with latest MPLAB for PIC ics with Pickit3.5 @ $25/- Vs ST-Link V2 @$2/-
Lastest version will not connect with pickit. After banging my head for over a week , I had to uninstall clean various folders and registry and install a previous version. With each try it showed signs of life. finally installed 4 versions back. It was nightmare each operation taking almost 2 to 3 hours. Now it is working nicely. These companies deliberately discontinue support of older well tried debuggers for their much costlier new products. There also the pics could be programmed using their old standalone utility
I am beginning to think, it is the same issue here too. STM may have silently withdrawn support for these cheap debuggers. Like the other one, I am able to program using standalone st-link utility which seems to be much better with comparison of file and device memory. The advantage of IDE for debugging is lost. May be it will work with an old version of Stm32CudeIDE too.
In my case even openCD doesn't work. on CubeIDE.
2024-05-11 09:43 AM
[I could upload the code by changing the plugin.]
plugin ? pls explain.
2024-05-11 04:21 PM - edited 2024-05-11 04:24 PM
> 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
This error message is misleading. It suggests that STM32_Programmer_CLI.exe is not found or could not run.
In fact there was a runtime error, caused by external loader(?)
Besides fixing the root cause, suggest to change the message. Instead or "opening" - "executing" or like that.
2024-07-10 01:10 AM
Any updates on this? We are experiencing what seems like the same issue as above.
We have tried uninstalling all existing STM software and reinstalled only the newest tools. Updated windows to the newest version as of 2024-07-10 (Windows10, version 10.0.19045, build 19045).
We are able to program the device using STM32CubeProgrammer but not using the STM_Programmer_cli.exe from CubeIDE.
2024-08-21 09:57 AM
@AndersRasmussen
I've been stuck for a few days now and despite all my research and attempts, nothing seems to have solved the problem. I've also uninstalled and reinstalled all the ST tools but nothing works. I'm using Windows 11 but I've never had any problems.
I can load my program with the .bin from STM32CubeProgrammer but I can't use the debugger from STM32CubeIDE 1.14 and 1.16.
I hope that the ST teams find a solution... quickly.
2024-08-24 04:33 AM
I've solved the problem. It was a hardware short on the uP's NRST. I was misled by the fact that it worked once.
2024-08-24 12:15 PM
Sorry!
I don't understand how you solved the problem.
Can you explain more?
2024-08-26 01:52 AM
My hardware consists of several PCBs linked via connectors. On 2 of them there is a button that allows the uP to be reset. The aim is for the reset to be as accessible on the PCB containing the uP as it is on the one for the HMI.
In the end, the uP reset is connected as follows:
When I press S5, the 0 ohm resistor R50 causes a short circuit on NRST.
According to the ST documentation, the pull-up resistor (Rpu, framed in red) for the NRST input is internal and fixed, so there is no need to add one.
I didn't understand why it didn't work because when I used STMCubeProgrammer I could load the program without any problem.
My intuition is that when using STMCubeIDE, at the time of debugging, the uP activates one of these outputs (framed in red) and pulls the transistor to ground. This causes the internal reset but it also causes the short-circuit due to my 0 ohm resistor R50. Conversely, when loading the program with STMCubeProgrammer, the uP does not activate the outputs because it uses the NJRST and this does not cause a short-circuit.
I simply removed R50 and C50 and that solved the problem.
I hope my answer is clear enough.