While_one project on the STM32F4-Discovery with a GNU ARM Eclipse template

In our previous post, we reported how easy it was to produce and run a blinking program on the STM32F4-Discovery with Eclipse IDE for C/C++ Developers, GNU ARM Eclipse, GNU Tools for ARM Embedded Processors and OpenOCD. It did however, leave me an impression that the project and executable were quite large. Let’s check how it really is.
Who says that “Hello world” is a simple program? It certainly isn’t in bare metal programming. Even blinking a LED is too advanced for our purpose which is to study in details the structure of the STM32F4xx C/C++ project template in GNU ARM Eclipse:

  • Source code
  • Makefile
  • Map file
  • In a lesser extent or just for fun, processor instruction level

To reach that purpose, we need no more no less than the while_one program:

In the Eclipse setup described in our previous post, we create a C project called while_one. It will be an STM32F4xx C/C++ Project, with the Cross ARM GCC toolchain.
Under “Target processor settings”, we choose an STM32F407xx with a Flash size of 1024 KB. The content is “empty”, we use no POSIX system calls and no trace output. We check “some” and “most” warnings, and leave the other settings as they are. We leave the standard folders as they are. We select the Debug and the Release configurations. We use the tool chain “GNU Tools for ARM Embedded Processors (arm-none-eabi-gcc)” and set the correct path to the bin folder (where arm_none_eabi_gcc is located).
The generated code is just what we need:

I have however a number of issues with the resulting project:

  • It does not run on target! More precisely, when trying to step over from the first row in main(), the OpenOCD console ends in a "Info : halted: PC: 0x08000cb4" forever loop. This is in contrast to the blinky program, that just runs as expected. Since the main() function is trivial, the problem must be related to the initialization that happens before main() is invoked.
  • The project includes 10 files from the STM32CubeF4 HAL. I have a hard time believing that while_one needs some much hardware support.
  • The project includes some files, for example _initialize_hardware.c, that are part of “the µOS++ III distribution”. Firstly, I find a bit strange to have some files included from a project that I did not intend to use (at least not right now). Secondly, just to take one example, __initialize_hardware() only enables the FPU, which is also done by SystemInit() in system_stm32f4xx.c, provided by STM32CubeF4 as specified in CMSIS. In other words, the template provides code that is redundant with what ST provides, that also is included in the project.

The observations above are pretty much enough for me to avoid using the STM32F4xx C/C++ Project template from GNU ARM Eclipse. The rest of it, GNU ARM C/C++ Cross Compiler Support and GNU ARM OpenOCD Debugging support still seems interesting, however. My next step will probably be to keep these two plugins, to remove GNU ARM C/C++ STM32Fx Project Templates from Eclipse, and to rebuild the while_one project from STM32CubeF4 instead.

2 thoughts on “While_one project on the STM32F4-Discovery with a GNU ARM Eclipse template

  1. Hi Alain,

    I regret you had problems with the template.

    > It does not run on target!

    this is a GDB problem, not being able to single step an empty loop optimised code. if you want to do this, please switch the debugger to assembly mode and you’ll be able to single step.

    > The project includes 10 files from the STM32CubeF4 HAL

    unused code is automatically removed by the linker, so you should have no problems, the files are there for just in case. if you are certain you do not need them, you can exclude them from the build.

    > __initialize_hardware() only enables the FPU

    this redundant FPU initialisation was already removed from the template, the next version will be released without it.

    if you have further problems with the plug-ins, please open new tickets in the SourceForge trackers.

    regards,

    Liviu

    • Dear Liviu,

      Liviu Ionescu on August 26, 2014 at 12:04 pm said:

      > Hi Alain,

      > I regret you had problems with the template.

      Thanks a lot, I really appreciate you taking the time of writing a reply.

      > > It does not run on target!

      > this is a GDB problem, not being able to single step an empty loop optimised code. if you want to do this, please switch the debugger to assembly mode and you’ll be able to single step.

      I didn’t know that, I do not often write empty loops. :-)

      I will keep it in mind.

      > > The project includes 10 files from the STM32CubeF4 HAL

      > unused code is automatically removed by the linker, so you should have no problems, the files are there for just in case. if you are certain you do not need them, you can exclude them from the build.

      I understand that. I was just being a minimalist at the project level too, willing to only add files when they really are required. Just a question of taste really, not a big issue.

      > > __initialize_hardware() only enables the FPU

      > this redundant FPU initialisation was already removed from the template, the next version will be released without it.

      Thank you for this.

      > if you have further problems with the plug-ins, please open new tickets in the SourceForge trackers.

      The issues I mentioned were not bugs per se. If I find bugs, I will try to open new tickets. Thanks again.

      Best regards,

      Alain

Leave a Reply

Your email address will not be published. Required fields are marked *