Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


opentag:tools:gnu_arm_eclipse

GNU ARM Eclipse (for STM32)

Using Eclipse CDT with GCC-ARM toolchain allows choices:

  • choice of host operating system: Mac, Linux or Windows.
  • choice of compiler backend, such as Sourcery CodeBench Lite ARM, Yagarto, devkitARM, etc.
  • choice of debugging adapter hardware.

This IDE setup provides very similar environment to TI Code Composer Studio.

Eclipse Installation

Visit eclipse.org downloads, look for “Eclipse IDE for C/C++ Developers” and download eclipse for your platform.
indigo-3.7.2 is good for GNU ARM.
If you do not already have a java runtime environment installed, visit JVM installation page.

Installing managed build extension for GNU ARM

This managed build extension generates makefiles so you dont have to think about them.
It connects the compiler/linker to eclipse.
Visit GNU-ARM extension installation instructions to add the managed build extension into Eclipse.

GNU ARM toolchain selection

Visit GNU ARM Eclipse Plug-in Wiki to see a table of available toolchains for your host platform. Generally the choice of free toolchain comes to this:

  • Sourcery CodeBench Lite ARM: prebuilt (time saver) for all platforms, with option of purchasing support from Mentor Graphics.
  • Yagarto: getting old, but has latest versions, not on linux.
  • devkitARM: for the hobbyist.
  • Summon ARM: build script if you want to build your own bleeding-edge toolchain.

(GNUARM and WinARM are considered dead)


Some say that codesourcery produces the leanest code, but its important to have alternatives to Mentor Graphics.

Zylin CDT plugin installation

Zylin plugin is the bridge between Eclipse and GDB.
It knows nothing about your particular target CPU platform, or how GDB talks your your target. It only provides GDB to eclipse.
Install Zylin the same way you installed GNU ARM Eclipse Plug-in (Help → Install New Software…), using URL http://opensource.zylin.com/zylincdt for repository location.
debugging session screenshot on STM32 target.

gdbserver installation

GDB server provides the connection between your debugging adapter and GDB.
You can use the gdbserver provided by the debugging adapter vendor, or use OpenOCD if thats the best option.
One example of a gdbserver provided by the debugging adapter vendor is SEGGER J-Link GDB server.
Another example is texane for ST-LINK found on STM32 discovery boards.
When considering using vendor provided server, its important to verify it supports your particular target CPU and will run on your host operating system.
The OpenOCD user manual has list of Debug Adapter Hardware, where some of those products could have their own gdbserver, or OpenOCD could be used instead.

Project creation: startup code and linker script

project creation

  • File → New → C Project, select the toolchain you have installed (and want to use).
  • give it a project name, and Finish.
  • source files are added by: right-click project (in Project Explorer) → Import → General, File system →
    • to have Portable Project, you can click Advanced button and enable linking.

startup code

TrueSTUDIO startup code works for GNU ARM toolchains.
In the case of STM32L1xx standard library, look in STM32L1xx_StdPeriph_Lib_V1.1.0/Libraries/CMSIS/Device/ST/STM32L1xx/Source/Templates/TrueSTUDIO directory for file for the density of your target CPU.
The filename extension of lowercase .s is not compatible with eclipse: copy the file to other location to rename it with upper-case .S extension.
Add this startup file to your project

linker script

TrueSTUDIO linker script works for GNU ARM toolchains.
In the case of STM32L1xx standard library, look in STM32L1xx_StdPeriph_Lib_V1.1.0/Project/STM32L1xx_StdPeriph_Templates/TrueSTUDIO.
A few scripts are there for high-desity and medium-density devices.
Copy the appropriate script for your target into your project directory and edit/verify the memory areas are correct for your particular target. Ensure that _estack is assigned correctly to end of SRAM.

As another example of startup for STM32F family, you would look in STM32F10x_StdPeriph_Lib_V3.5.0/Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x/startup/TrueSTUDIO for startup code, and STM32F10x_StdPeriph_Lib_V3.5.0/Project/STM32F10x_StdPeriph_Template/TrueSTUDIO for the linker script for the specific CPU in STM32F family.

project properties

Setting project properties is familiar to users Eclipse, such as TI CCS, etc.
For GNU ARM, first attention is to assigning linker script file at Project → Properties → C/C++ Build → Settings → under linker, General: set your -T linker script file, and uncheck -nostartfiles
-nostartfiles has to do with including a crt.o which provides _init
2nd attention is to include path: C Compiler → Directories
Linked Resources and Build Variables can be used Portable Projects, if source files are not located under workspace directory.

predefined macros

GCC for ARM predefines __BYTE_ORDER__ to __ORDER_LITTLE_ENDIAN__
Use that for conditional compiling byte order.
To list all predefined macros:

arm-none-eabi-gcc -dM -E - < /dev/null | sort

include paths

If in the problems tab, you get Semantic Error “Symbol x could not be resolved”, then you need to add an include path under Project Properties → C / C++ General → Paths and Symbols. This is for eclipse IDE.
The paths for compiler are under C / C++ Build → Settings

size optimization

For smallest program size: Project properties → C / C++ Build → Settings:

  • ARM C compiler:
    • Optimization level: -Os
    • enable -ffunction-sections
    • enable -fdata-sections
  • ARM C Linker:
    • Remove unused sections (-XLinker –gc-sections)

newlib and printf

If your toolchain (such as sourcery lite) uses newlib, and your C program calls printf, then you need to concern yourself with adding a few syscalls to provides some dependencies needed by newlib.

debugging for the first time

After you have built your project, and you have a <workspace>/<project>/Debug/<project>.elf file, you can now run it on your target using GDB.
Its best to run GDB in a console first to make sure everything is functional.
When its working OK, then you can put all startup commands into the Eclipse Zylin debug configuration for a much better user experience.
These steps involve connecting your debugging adapter hardware to your target, and starting the gdbserver on your host.

With console in directory <workspace>/<project>/Debug, running arm-none-eabi-gdb <project>.elf, the following commands in .gdbinit:

target remote :2331
set mem inaccessible-by-default off
monitor speed auto
monitor endian little
monitor reset
monitor flash device = STM32L152VB
monitor flash breakpoints = 1
monitor flash download = 1
load
monitor reg sp = (0x08000000)
monitor reg pc = (0x08000004)

Pay special attention to correct addresses assigned to sp and pc
sp must have _estack address
pc is start address

OpenOCD startup example

If your debugging adapter vendor provides OpenOCD, then use their provided OpenOCD.
Alternately, you can build it from git repository
As described at running openocd, openocd is started:

  openocd -f interface/ADAPTER.cfg -f board/MYBOARD.cfg

Make yourself a .cfg for your board by copying the most similiar board.cfg using your target CPU family, and edit WORKAREASIZE for your target ram size, and edit source for your target.
Some board .cfg files call a particular debug interface.

Starting GDB with OpenOCD is described here.

Typical gdb startup with OpenOCD

In your Zylin initialize commands, or .gdbinit if running from console.

set remotetimeout 90    # for lengthly operations
target remote :3333     # connect gdb to openocd
mon flash probe 0       # discover what chip we're connected to
mon flash write_image erase yourproject.elf
mon reset halt

Recommended to first test flash loading using the above flash write_image erase rather than load from gdb. Downside of writing flash image using monitor command is you need to give openocd the full path to .elf file. If attempting load from gdb, use verify_image to openocd to check if programming was correct.


reset target in OpenOCD: use mon reset halt, then single step. You should be stepping at start of Reset_Handler.

trying it with Eclipse Zylin plugin

To ensure you have correct sequence of GDB startup, put your startup commands into a .gdbinit. From console, you must start GDB and load firmware into target completely from .gdbinit, then run target with 'c' at gdb prompt. When target is running, ctrl-C to halt and single step to verify target is running your code. Try setting a breakpoint if you want to test that.
Now that you have GDB working in the console, you can launch a debug configuration in Eclipse.

  • Run → Debug Configurations…
  • If first time, double-click Zylin Embedded Debug (Native)
    • in GDB Debugger, put arm-none-eabi-gdb (or whatever your toolchain's GDB is named)
    • in the commands tab, paste in all the commands needed to start, that you tried on command line or .gdbinit.
  • click Debug button
  • eclipse will now change to debug perspective and GDB will start.
  • example screenshot
  • no reset button in IDE: to reset target monitor reset in console tab, then hit single-step button. (or mon reset halt for openocd)

Register view

Register viewing eclipse plugin might support your cpu, check plugin page http://embsysregview.sourceforge.net/
Enable it: Window → Show view → EmbSys Registers
You may drag the tab elsewhere.
click on wrench to select CPU type.
Additional cpu can be added by XML editing.

GIT source control

For GIT integrated into Eclipse, try EGit.

opentag/tools/gnu_arm_eclipse.txt · Last modified: 2012/03/14 20:38 by dudmuck