Jul 01

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.