I received my STM32F4-Discovery evaluation board last week. So I setup the required development environments and did a quick test.
The STM32F4 is an ARM Cortex-M4 processor with DSP and FPU instructions. Since I have not used any ARM MCU before, I decided first to use the recommended tool chain to get myself started.
According to the user manual (UM1467), the following IDEs have native support for STM32F4-Discovery board:
- IAR Embedded Workbench for ARM (EWARM)
- RealView Microcontroller Development Kit (MDK-ARM)
- Atollic TrueSTUDIO for STM32
- Altium TASKING VX-toolset for ARM
And it seems that only the Atollic TrueSTUDIO has a free version (Lite) that does not have any code limitations. So the Atollic IDE is the pretty obvious choice for me.
The IDE is based on the popular open source Eclipse development environment. Having used it extensively with C++ and Java projects, setting up the demo project is pretty straight forward. Atollic TrueSTUDIO also integrates with ST-Link GDB server, which makes debugging within the IDE very easy (see screenshot below)
To upload the compiled code onto the STM32F4 board, we will need the STM32 ST-LINK utility.
Atollic TrueSTUDIO builds the project target into ELF format which cannot be uploaded to the development board directly. So we will need to first convert the target from ELF to Intel HEX. Unfortunately, the lite version does not seem to provide such a conversion utility.
After some searching, I found that Ronetix ARM toolset contains arm-elf-objcopy which can be used for such conversion. The full Ronetix tool chain can be downloaded from here.
To convert the ELF file to HEX, use the command below:
STM32F4-Discovery_FW_V1.0.1\Project\Demonstration\TrueSTUDIO\STM32F4-Discovery_Demo\Debug
arm-elf-objcopy -O ihex RCC.elf RCC.hex
Now we can use the ST-LINK utility to upload the .HEX file onto the STM32F4-Discovery board. Interestingly enough, the converted HEX file is about 17 kB smaller than the pre-compiled project demonstration file in the binary folder. It works without a glitch nevertheless. I suspect that the ST supplied HEX file might have been compiled with more debugging information.
