2020-01-13 08:11 PM
I am generating code using STM32CubeIDE, but when I start to debug I am getting errors like:
"STMicroelectronics ST-LINK GDB server. Version 5.2.3
Copyright (c) 2019, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Waiting for debugger connection...
Debugger connected
Debugger connection lost.
Shutting down..."
I am using the latest version of st-link USB driver(en.stsw link009). Also I am using USB to TTL converter. Initially everything was working very well, near about ten code executed successfully. But now facing the above error. So how can I solve it?
Solved! Go to Solution.
2020-12-01 04:51 AM
same problem here, no solution jet??
2020-12-03 02:24 PM
I got the same problem with two brand-new NUCLEO-L476RG boards.
I think the root cause lies somewhere in the pre-flashed memory, because in trying the bulk erase process that ATRev attempted worked for me.
As I said, this worked for me using the Cube toolchain (code generated in CubeMX, edit/compile/debug in CubeIDE).
Good luck!
2020-12-04 12:20 AM
Hi,
Yes, erasing flash is a good thing.
But the STLink gdb server should be able to erase the flash itself and reprogram the appli.
Try with CubeIde 1.5.0 and select "Connect under reset" mode (default reset mode) to be able to connect if appli uses SWD pins or low power modes and It should be able to erase the flash (STLink gdb server using CubeProgrammer cli).
Rgds,
Laurent
2020-12-04 01:11 AM
We have seen issues with a few number of devices that the user is forced to perform a mass erase before being able to flash a new bianry. This is obviously a bug and we try to fix it for the next version. If you do run into this problem with CubeIDE and ST-LINK GDB server then you can try to add the following to force a mass erase before programming the new binary:
In your debug configuration > Startup tab > Initialization commands > Add: monitor flash mass_erase
This will force CubeProgrammer_CLI version to peform a mass erase before programming new content. At least it automates the procedure you describe @GNels.2 in your post above.
Other issues leading to debugger connection lost after the initial launch of your application typically includes:
2020-12-04 08:24 AM
Thanks! That works well. We'll put it in our knowledgebase.
2021-01-08 02:40 AM
I had the same problem. I changed the USB cable, now it works.
2021-05-11 01:10 PM
Got the same problem. @mattias norlander's solution didn't work for me, but @AT.1revisan 's one did.
Here is what I did exactly (source at https://www.st.com/resource/en/user_manual/dm00613038-stm32cubeide-stlink-gdb-server-stmicroelectronics.pdf, page 8):
Done. After that STM32CubeIDE could run and debug my program correctly.
2021-05-28 05:50 AM
I had the same problem.
I tried adding "monitor flash mass_erase" to the debug configuration, as suggested above, without solving the error.
But,
I opened a new project on CubeIDE, just an empty project.
I loaded it onto the MCU and it removed the error.
Going back to my original project the problem disappeared.
That's my 2 cents.
Mauro
2021-06-19 02:38 PM
I followed precisely these steps and it worked for me. Thank you for guiding through them, @paul19! (the solution by @mattias norlander unfortunately also didn't work for me)
I can at last start with my brand new Nucleo board after a day of frustration and looking for solutions.
2021-08-12 12:54 AM
I had the same issue with my STM32L071. The problem turned out to be with flash memory address in linker script. I accidentally changed it to 0x80000000, when it supposed to be 0x08000000. That's why the debugger couldn't flash the MCU with my program. Hope it helps someone.