5
\$\begingroup\$

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:
Load failed
Failed to execute MI command: load C:\Development\stm32-test\Debug\stm32-test.elf
Error message from debugger back end:
Load failed
Load failed

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?

\$\endgroup\$
5
  • \$\begingroup\$ Perhaps a silly question, but are you sure your .elf file is being generated? Is the path correct? \$\endgroup\$
    – bitsmack
    Nov 27, 2015 at 8:45
  • \$\begingroup\$ @bitsmack: yep, triple-checked. Even moved the .elf to a different path, converted Windows slashes to Unix slashes etc. Always the same error. \$\endgroup\$
    – Violet Giraffe
    Nov 27, 2015 at 9:05
  • \$\begingroup\$ @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? \$\endgroup\$
    – Violet Giraffe
    Nov 27, 2015 at 9:12
  • 1
    \$\begingroup\$ 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? \$\endgroup\$
    – Bence Kaulics
    Nov 27, 2015 at 9:16
  • \$\begingroup\$ @BenceKaulics: that did it, I missed the flash address adjustment part of the article! Thank you, please post this as an answer. \$\endgroup\$
    – Violet Giraffe
    Nov 27, 2015 at 9:28

1 Answer 1

Reset to default
6
\$\begingroup\$

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:

enter image description here

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.