Failed to execute MI command

[Robert Ritchey]

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.

[Markus GIRDLAND]

Next step would probably be to activate the gdb server log in the "Debugger" tab of your debug configuration.

It generates a log with more information.

[Robert Ritchey]

Thank you, I looked everywhere for a log file but missed this option on the debugger tab.

[Robert Ritchey]

I turned on the log as stated above. It really did not supply any more information. I did find another log file under in the metadata folder. It seems more detailed but neither really gives me any clue where to start looking to solve this. Seems I cannot attached two files so I am attaching the metadata log file.

[Robert Ritchey]

OK, one more weird thing. I had done a quick project using the Discovery STM32F072 board. I just ported that to STM32CubeIDE and ran it. It gets into the debugger just fine. This makes me think there is something funky between the debugger and the ST-LINK as using STM32CubeProg and I can program and erase the MCU, change the option bytes, etc.

[Robert Ritchey]

HI, I did one last test. I generated a new project as an STM32 project. It compiled after some tweaking but when I tried to debug it failed too. So for what ever reason it seems that the debugger is not talking to the ST-LINK correctly. Same error messages. Honestly this is frustrating, What could be worng?

[Robert Ritchey]

So, I got it solved but it somewhat puzzles me. The first time I went to download my code I had set up the loader script to write to the option bytes. Accidentally I wrote a wrong value to the nUSER which cleared the bits. and protected all the memory sectors. I discovered this error with CubeProgrammer by trying to bulk erase the unit and having it fail. I fixed the protection and set the ParityCheck and VDDA Monitor. I left the nRST_STDBY, nRST_STOP and WDG_SW cleared. I wanted the unit to reset on standby, stop and enable the hardware watchdog. So, I ended up trying a virgin board of another design that was built but I had not tried to debug yet. I downloaded my simple test program and it worked. So, the only thing I could think of was the option bytes were not at the factory setting on the board I was having trouble with. I set all the bits in nUSER and tried again and it worked. This is great but it brings up questions.

1) I have always been able to bulk erase any manufacturers' processor, even when memory protection is on. It was not clear to me that the ST parts were different from the user manual. I went back and could not find this stated anywhere.

2) I am not sure which bits caused the debugger to crash but it seems I should be able to reset the nRST_STDBY, nRST_STOP and WDG_SW bits and still be able to debug. Is this a false assumption, and if so, which of these three bits causes the debugger to crash (or ALL)?

Thanks,

[Nbaşa.1]

I have a same problem and I dont know how to solve it. Please help me?

[LHarr.1]

Hi all, I am getting the same error. Crated a new project, added a toggle GPIOB, delay to blink the green LED and tried to run it. It fails with this error. I note that ST-LINK was updated at the begining of my session. I am new to this NUCLEO board so not sure if it was working before the firmware update.

[Nbaşa.1]

Hi , I have this error and maybe, keil make mistake which is "Cortex-M7 fault error ". Also, I have two KEİL IDE in different computers. Keil gives an error on one and not on the other.

[Graham1904]

I am getting exactly the same problem. A program using the Nucleo-64 with STM32L073RZ gives no problems, another program, even a blank new project, with Nucleo-64 with STM32L476RG gives

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

[BillE]

I too am getting the same problem.

The things I have noticed are:

1. A lot of us are getting this problem.

2. Those lucky enough to solve it did it entirely with no help from STM.

3. The solutions they found seem weird, random and all over the place with no consistent pattern.

For me, I had a perfectly healthy project with lots of files.  My Windows10 PC died and I replaced it with Windows 11.

When I ran STM CubeIDE, I was forced into upgrading the project.

Details of error message "Failed to execute MI command" are next to useless:

Error in final launch sequence:

 

Failed to execute MI command:

load ...\\SDV1B\\Debug\\SDV1B.elf

 

Error message from debugger back end:

Error finishing flash operation

Failed to execute MI command:

load ...\\SDV1B\\Debug\\SDV1B.elf

 

Error message from debugger back end:

Error finishing flash operation

Failed to execute MI command:

load ...\\SDV1B\\Debug\\SDV1B.elf

 

Error message from debugger back end:

Error finishing flash operation

Error finishing flash operation

[Pavel A.]

@BillE After upgrade of Windows, please check the USB connection to the board (the drivers... you know). Use the CubeProgrammer, as other people did above, or other program that works with ST-LINK. Validate that it can connect to the board and load a program.

 

[VKais.1]

I am using STM32CubeIDE 1.4.2, a Nucleo STM32F072RB, and the ST-LINK GDB server debugger.

I had a project that worked fine. I created a new project to test a weird issue I was having with the other project, and had no problems (no error, no weirdness). When I went back to the original project - I started getting this error about the .elf file. I tried everything - I spent more than half a day on the #$%^ing thing.

What ended up working for me (your results may vary) was copying the STM32F072RBTX_FLASH.ld file from the working project to the broken project. My original project never had it (I checked my git history), but for some reason when I copied it from the working project to the broken project - problem fixed.

I'm not sure whether that's THE fix, or one element in everything else. The original project had a .cfg file the new project never had, and I definitely cleared out files created by debugging to reset them. None of those on their own fixed it.

I think some setting was changed when I created the new project and it affected the original.

Good luck!

[SPoly.1]

Erasing the whole flash using Stm32Cubeporgrammer has helped me to solve this problem