Failed to execute MI command

Robert Ritchey · ‎2019-09-17

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

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.

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 · ‎2019-09-18

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 · ‎2019-09-18

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

Robert Ritchey · ‎2019-09-18

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 · ‎2019-09-18

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 · ‎2019-09-18

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 · ‎2019-09-18

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 · ‎2020-03-26

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

LHarr.1 · ‎2020-03-29

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 · ‎2020-03-30

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.