Yet another "Failed to execute MI command" problem...

[White_Fox]

Hi guys

This project here was built and debugged fine last week. Today, I get this message:

'Launching has encounteres a problem.

Error in final launch sequence:

Failed to execute MI command:
-environment-cd
<Path/to/project>

Error message from debugger back end:
<Path/to/project>

Here is the whole console output:

 

STMicroelectronics ST-LINK GDB server. Version 7.8.0
Copyright (c) 2024, 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
 InitWhile : Enabled

Waiting for debugger connection...
Shutting down...
Exit.

 

There are a lot posts with "Failed to execute MI command" problems here, but I did not find mine. I hope, somebody knows how to fix that. As I said, running and debuging the project worked nice some days ago, and I do not see reason why it does not continue its fluent work today.

 

 

 

[Semer CHERNI]

Hello @White_Fox 

First let me thank you for posting.

 

Are you still facing the same misbehavior?

If it's the case, can you change the port used by GDB server.
Also, can you try to run the GDB server manually from the CLI?

KR,
Semer.

[White_Fox]

---

@Semer CHERNI wrote:

Hello @White_Fox 

First let me thank you for posting.

 

Are you still facing the same misbehavior?

If it's the case, can you change the port used by GDB server.
Also, can you try to run the GDB server manually from the CLI?

KR,
Semer.

---

Hi everyone

Finally, I fixed it by myself, so I'm unfortunately not able to try other solutions anymore.

The fix was:

1. Copy the project folder
2. Delete everything but the .ioc (CubeMX file) in the project folder
3. Let CubeMX build a new project
4. Put the sources from the copy back into the new clean project.

It works now again, so I assume that some project settings get broken. It's a kind of ram hammer method, but it worked quickly. (I'm glad enough to have no need for further setting stuff like importing arm_math.h stuff, as I have in a parallel project.)

[Pavel A.]

Funny characters in the project path, again. Recipe for trouble.

 

[White_Fox]

---

@Pavel A. wrote:

Funny characters in the project path, again. Recipe for trouble.

 

---

Yes, that's right, but to be honest, we are not in the eighties anymore even we are still using C. Modern software should be able to handle also no-ASCII-characters, I think. Other software can handle it too.

[Michael-Lore-China]

I designed a PCB using the STM32F410 microcontroller. Initially, when I tried to download code using the ST-Link V2, I encountered the same problem repeatedly.

To troubleshoot, I pressed the Reset button on my PCB before starting the debugging process with STM32CubeIDE. As STM32CubeIDE attempted to connect to my PCB, I released the Reset button. This method sometimes allowed me to successfully download the code, but it mostly failed.

Next, I added a 10K pull-up resistor to the SWDIO line and a 10K pull-down resistor to the SWCLK line. With these modifications, I was able to successfully download the code 100% of the time without needing to press the Reset button at all.

Interestingly, the same ST-Link V2 worked flawlessly with another STM32F103 PCB board I purchased online. There was no need to press the Reset button during the download process, and this board did not have any pull-up or pull-down resistors on the SWDIO/SWCLK lines.

My conclusion is that the pull-up and pull-down resistors have a significant impact on the SWD connection, but this impact varies depending on the specific version of the STM32 microcontroller.

I hope this will help you and others in the future 100 years.