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.

Jun 29

Running an STM32CubeF4 template on the STM34F4-Discovery

STM32CubeF4
Led by The Definitive Guide to ARM® Cortex®-M4…, we have quite easily managed to compile and run a sample from GNU Tools for ARM Embedded Processors (see earlier post). However, we only got a generic Cortex-M4 startup assembly file and corresponding linker script from the sample. According to The Definitive Guide to ARM® Cortex®-M4…, there is more we can get from our vendor, ST in this case (HAL headers and code, drivers, and more generally, all sort of boilerplate code we want to have when we make full use of the board’s resources, instead of reinventing the wheel). STM32CubeF4 is just that, and quite a lot more (especially plenty of example applications and templates). It complies to The ARM CMSIS, Cortex Microcontroller Software Interface Standard, a vendor-independent hardware abstraction layer for the Cortex-M processor series that also specifies debugger interfaces.
What I am most interested in is the contents of Projects/STM32F4-Discovery/Templates/, as it should contain exactly what we need to develop applications for the board (although I am not sure whether it includes support for C++ compilation, which I intend use, but the ARM variant used in an earlier post did have such support, so it should be easy enough to copy/paste).
Projects/STM32F4-Discovery/Templates/ contains project files for several development environments, but no Makefile. One of the supported environment is TrueSTUDIO, that seems to make use of a GNU chain, which is good for us.
I might as well take the opportunity to digress a little about the development environment topic. I won’t apologize for loving open source. No single software vendor has a chance to have nearly as many reviewers as an open source tool. Many reviewers just means higher quality, it’s that simple. Using a GNU toolchain is not even a topic of discussion for me. Using openocd, including its integration with GDB has been very positive so far, so I do not see a reason for looking elsewhere. What is left to choose is:

  • The editor.
  • The debugger GUI (living without a debugger GUI is not really an alternative).
  • Last but not least: the build tool.

Concerning point 1, although I have used Emacs many years, I am leaning towards Eclipse because it is the de facto standard. The reason is that I also develop software for a living, and Eclipse is probably preferable for a potential customer. It is easier to get a consensus around it. The debugger GUI issue is then solved as well (with the right plugins). When it comes to the build tool, I want to be able to build both inside and outside of Eclipse. I reckon that will ease the generation of production binaries, and I also reckon that GNU make and its Makefile are the natural solution for that issue.

GNU ARM Eclipse
I have investigated the fastest way to get a blinking LED example running/debugged under Eclipse:

  • Download Eclipse from Eclipse IDE for C/C++ Developers. Unpack it wherever you like and start it from there.
  • Install GNU ARM Eclipse, as documented under GNU ARM Eclipse plugins installation. GNU ARM Eclipse is a set of plugins, quoting the site: “currently maintained by Liviu Ionescu, a senior IT engineer, with expertise in operating systems, compilers, embedded systems and Internet technologies”.

GNU ARM Eclipse is certainly impressive. Once that was installed, using the documentation from the same site, GNU Tools for ARM Embedded Processors, and OpenOCD, I could run/debug a LED blinking example and see printouts from the program in an Eclipse console in no time, without even using STM32CubeF4. It should be however noted that some code in the plugin, I guess most of what is specific to ST MCUs and boards, comes from STM32CubeF4.