STM32F3 Discovery + GNU ARM plugin + OpenOCD - cannot load the binary onto the board

I'm using the GNU ARM plugin for Eclipse with Open OCD as a debugger. This is on Windows 10 x64. The problem I'm facing is the following error when trying to debug or run the sample program:

Error in final launch sequence
Failed to execute MI command: load C:\Development\stm32-test\Debug\stm32-test.elf
Error message from debugger back end:
Failed to execute MI command: load C:\Development\stm32-test\Debug\stm32-test.elf
Error message from debugger back end:

There are several kinds of STM32 project templates that the ARM plugin offers. Most notably, there's the "STM32Fxxx C/C++ project", and it works out of the box no problem. But it's bundled with the old version of STM32 library. I wanted to use the latest STM32F3Cube, so I used the other template - "Hello World ARM Cortex-M C/C++ project", as per the recommendation of this article. It's designed for use with the STM32F3Cube, and it's the one I can't load onto the board.

Please tell me what further information is needed for dealing with this issue, or how I can collect more detailed logs etc.

P. S. I have compared the debug configuration settings between the working and non-working projects, and found no difference. Same .cfg file, along with everything else. Is my .elf being rejected because there's something wrong with it?

• Perhaps a silly question, but are you sure your .elf file is being generated? Is the path correct? – bitsmack Nov 27 '15 at 8:45
• @bitsmack: yep, triple-checked. Even moved the .elf to a different path, converted Windows slashes to Unix slashes etc. Always the same error. – Violet Giraffe Nov 27 '15 at 9:05
• @bitsmack: I've just tried the following: opened the problematic project -> Debug configurations, and instead of this project's binary, specified the elf from the other, working project that I mentioned. So, I used this project's configuration to launch a different .elf, and it worked. Apparently, there's something with how the .elf itself is compiled. Any idea? – Violet Giraffe Nov 27 '15 at 9:12
• The RAM size and Flash size options in your project match the target board? And also, there is a part in the article, where you have to modify the Flash starting address in the mem.ld script. All of these steps are done in you case? – Bence Kaulics Nov 27 '15 at 9:16
• @BenceKaulics: that did it, I missed the flash address adjustment part of the article! Thank you, please post this as an answer. – Violet Giraffe Nov 27 '15 at 9:28

From the error message it seems that the debugger cannot locate where the Flash begins, so it fails to load the file.

In the F4 HAL Eclipse template this Flash origin address is set correctly for an STM32 but because you are using a general Cortex-M project, and so this address is not correct for an STM.

This step is described in the article you have mentioned. From the article:

We need to configure how the application is mapped in the MCU memory. This work is accomplished by the link-editor (ld), which uses the three .ld files inside the /ldscripts Eclipse folder. The file we are interested in is mem.ld, and we need to change the FLASH origin address from 0x00000000 to 0x08000000, as shown below:

...
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
...


This value can be obtained from the datasheet. Here is the relevant part:

protected by clabacchio♦Feb 28 '18 at 16:07

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).