Skip to main content
Robert Ritchey
Senior
September 17, 2019
Question

Failed to execute MI command

  • September 17, 2019
  • 16 replies
  • 40987 views

I am trying to debug my hardware for the first time. I was working in TrueStudio 9.3.0 as I had started this project in it before STM32CubeIDE came out. When I started to try to debug my program to day I got an error. OK, maybe I should try STM32CubeIDE instead. Loaded this up and got the project migrated with no problem. But when I go into the debugger it generates the same error and exits. I am not sure where to start to track this down. The console shows this:

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...

The detailed error message gives me this:

Error in final launch sequence:

Failed to execute MI command:

target remote localhost:61234

Error message from debugger back end:

Remote communication error. Target disconnected.: Success.

Failed to execute MI command:

target remote localhost:61234

Error message from debugger back end:

Remote communication error. Target disconnected.: Success.

Remote communication error. Target disconnected.: Success.

I am using an ST-LINK\V2. I can download the program just fine using STM32CubeProg so I know the ST-LINK and the interface is working correctly. Where do I go next to figure this out? Thanks.

16 replies

MRahi.3
Associate II
June 8, 2021

Hello, I hope someone had an answer to this problem since it was posted a year ago. I am currently trying to program an STEVAL-ESC001v1 board with an STLINK V2 ISOL probe. The IDE I use is the STM32CubeIDE. Before that, I used a regular STLINK V2 probe and the debugging of my program worked perfectly. Ever since I switched to the STLINK V2 ISOL (for isolation from power), I have been getting these errors on the console :

STMicroelectronics ST-LINK GDB server. Version 5.8.0

Copyright (c) 2020, 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...

Debugger connected

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Debugger connection lost.

Shutting down...

0693W00000BaQ4tQAF.png 

I tried using the STM32CubeProgrammer software, but It seems like the ISOL probe doesn't recognize the target :

0693W00000BaQCJQA3.png0693W00000BaQCTQA3.png 

Can anyone help me out with this issue ? Thank you very much

Visitor II
January 21, 2025

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.

罗卫华 2025.1月

2Days Later, when I attempted to run the debug session with CubeIDE, I cannot connect to my target board, received the same error. But download function is OK. Then I checked my PCB design, I found a issue. The SWDIO/SWCLK from MCU are firstly connected to a 4pin connector, and then routed to a usb type-c connector. These unused extra lines have significant impact on the communication with STLINK V2. Then I cut them from the 4pin connector, the Debug function ran just quite stable.

走线问题.png

 

 

My conclusion: 1. SWD wires must be pulled up or down. 2. There couldn't be any stub on the SWD trace.

Visitor II
February 21, 2025

I solved that error by activating serial wire in pinout and configurations > sys > debug: serial wire

Visitor II
August 12, 2025

Had the same problem. When I connected both usb ports [one through ST-LINK\V3-SWD and one directly to other USB VCP it works!], when I disconnect USB VCP it does not work. Seems to be current/voltage related.

No CubeIDE reset helped. 

No Cubeprogrammer erase helped.

No PC restart helped.

No debugger server port reset helped.

Luckilly my board had two (2) usb ports => more current to put MCU in configuration mode!

[some other guy even connected pull up resistors, or SWD flying wires].

 

Associate III
September 25, 2025

I got this error because I defined a sector in linker script for external memory-mapped PSRAM memory without NOINIT attributes and without placing init values into Flash. It caused elf and hex file to contain zeroes on memory mapped address and obviously debugger failed to write those.

Visitor II
October 18, 2025

I never had such problem before. But when I replaced the 0.uF capacitor between the NRST(reset) with a 47uF, I suddenly had the download error message as below (I used internal pull-up for the NRST which is about 40Kohms according to the datasheet). I found that when downloading the .elf file, the ST-LINK reset the board once.

After I restored the NRST circuit by removing the 47uF capacitor, the download worked fine.

I put 47uF to make some delay in reset (to make delay in starting the CPU) and it seems that the NRST(reset) delay made download issues when using ST-LINK/V2 and SWD.

 

Error messages :

Error in final launch sequence:

 

Failed to execute MI command:

load C:\\Users\\user\\Desktop\\DRYER\\Firmware\\DRYER\\Debug\\DRYER.elf

 

Error message from debugger back end:

Error finishing flash operation

Failed to execute MI command:

load C:\\Users\\user\\Desktop\\DRYER\\Firmware\\DRYER\\Debug\\DRYER.elf

 

Error message from debugger back end:

Error finishing flash operation

Failed to execute MI command:

load C:\\Users\\user\\Desktop\\DRYER\\Firmware\\DRYER\\Debug\\DRYER.elf

 

Error message from debugger back end:

Error finishing flash operation

Error finishing flash operation