cancel
Showing results for 
Search instead for 
Did you mean: 

Failed to execute MI command load .elf

Todoroff
Associate II

Hi everyone! 

I have a STM32F412RET7 MCU and I made myself a breakout board. However when I try to upload a code I get an error: Failed to execute MI command ... load .elf. This is written in the log file:

Log output file: C:\Users\GOSHOA~1\AppData\Local\Temp\STM32CubeProgrammer_a02884.log

ST-LINK SN : B55B5A1A00000000C8BEF001

ST-LINK FW : V2J42S7

Board : --

Voltage : 3.33V

SWD freq : 4000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x441

Revision ID : Rev C

Device name : STM32F412

Flash size : 512 KBytes

Device type : MCU

Device CPU : Cortex-M4

BL Version : 0x91

 

 

 

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a02884.srec

File : ST-LINK_GDB_server_a02884.srec

Size : 3.88 KB

Address : 0x08000000

 

 

Erasing memory corresponding to segment 0:

Erasing internal memory sector 0

Error: failed to erase memory

 

 

Error: failed to erase memory

Encountered Error when opening C:\ST\STM32CubeIDE_1.13.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.0.202305091550\tools\bin\STM32_Programmer_CLI.exe

Error in STM32CubeProgrammer

Shutting down...

Exit.

I've tried to upload using ST Link Utility, but I cannot find a file supported by it. I tried the CubeProgrammer also and when I try to download the code to the MCU it says Operation succsessful, but the LED doesn't blink. I tried with all kinds of programmers, updated their firmware, I've changed a lot of options in the debugger section of the STCubeIDE, but again it's the same result. I've also tried to program a blue pill board. Again the same result. The strangest of all is that some time ago it actually succeeded, however I didn't understand how.
Could anyone give me an advice?

Thank you!

1 ACCEPTED SOLUTION

Accepted Solutions

Well, the STM32F412RET7 behave correctly. However, only fakes have been installed on the Bluepills for a long time, so you should ask the respective manufacturer of the fake.

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

9 REPLIES 9
Peter BENSCH
ST Employee

Welcome @Todoroff, to the community!

It looks like you are using an ST-LINK/V2, right? Please upload a photo of it so that we can have a look at it.

Regards
/Peter

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Sorry for the late reply. I have ST-LINK/V2 and a clone also. Both were not working. However few days ago I was manage to upload code from both of them successfully. I think that the problem was that I was powering my boards(STM32F103C6T6 blue pill and a homemade board with STM32F412RET7) from the the devices. The next thing that was strange to me was how the two boards got programmed. To program the blue pill via SWD I had to pull the BOOT0 pin high, upload the code, then pull it low again and press the RESET button. While the board I made with the 32F412RET7 MCU has the BOOT0 pin pulled low constantly. Just uploaded the code, pushed the reset button and it started working. I've read the AN2606, AN4488, watched hundreds of videos and read here also, but the thing with these pins still seems a bit unclear. 
As far as I can understand the configuration of these pins(or just BOOT0 when there is no BOOT1 pin on the MCU package) determines from where the MCU will load the firmware. What I didn't understand is why happened what I described in the upper part. Also, if I want to upload my firmware on the flash memory on the MCU the BOOT0 pin should be low, upload it via SWD, click on the reset button and the program will start executing, right? 
Thanks in advance! 

Well, the STM32F412RET7 behave correctly. However, only fakes have been installed on the Bluepills for a long time, so you should ask the respective manufacturer of the fake.

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Again, sorry for the late reply. I am glad to hear that actually I've managed to make it bare metal. Are there any tutorials of STM32 bare metal implementing? Can we find them here in the site? 
Thanks in advance and have nice holiday! 

Pavel A.
Evangelist III

@Todoroff You wrote that you have viewed hundreds of videos and many other articles provided by ST. What is missing? What specific details do you need about "bare metal implementing"?

These BOOT pins were unclear to me, but thanks to @Peter BENSCH I think I've understood it. The problem started with the error I got during programming, and I started to blame these pins and the mode that they put the MCU in. Regarding those BOOT pins I've understood that if I want to program the Main Flash memory with the firmware I wrote, the BOOT0 pin should be tight to ground via 10k resistor. After that connecting it to the ST Link programmer, programming it with the Serial Wire and finally pushing the reset button should do the job, right? 

Thanks in advance! 🙂 

Pavel A.
Evangelist III

@Todoroff If you're using ST-LINK for programming, the BOOT0 pin and BOOT1 does not matter at all. Connect it to "normal state" as it should be connected to start the user application. If BOOT0 on your STM32 is not a dedicated pin  (as Peter explained), set the option bit that controls it to the "normal state", to start the user application. And forget about BOOT0/BOOT1.

You wire the RESET pin of ST-LINK to NRST of STM32 and use "connect under reset" mode. In this mode the programming software can connect to the STM32 and flash it, no matter what the firmware does.

On the other hand, if you wanted to program via some other interface (USB DFU, UART...) then you have to set the BOOT0 to start from the built-in bootloader code. But this fortunately is not your case.

Hope this resolves the confusion.

 

Now is even more clear! Thank you guys! : ] How about the "Failed to execute MI command load .elf" error? 

Pavel A.
Evangelist III

>How about the "Failed to execute MI command load .elf" error? 

This message means that the CubeIDE debugger asked the lower-level ST-LINK driver (either "ST-LINK GDB server" or OpenOCD) to download your program .elf file to the MCU - but this action failed. This is all we know, unless you have more logs to share. This action takes several steps and has a lot of possible reasons to fail.