OpenSource ARM Development using Eclipse and OpenOCD

Author: Richard Ballard

Date Created: 15/05/13

Date Modified: 19/06/13

Version: 1.1

This tutorial is about using open source products to create a development environment that can be used to program various embedded systems. I'll be focusing on ARM based chips and in particular the STM32 flavoured cortex chips.
 

I'm doing this, as all the current recommended tools are expensive (unless crippled) and so are inaccessible for students like me. More importantly, these tools don't operate under alternative operating systems such as Linux and Mac OSX. The open source community has built a large range of tools for the individual components and these support a large range of devices but these tools are all developed separately. Some of these don't have very good documentation while others seem overly complicated. I will be using Eclipse with a couple of plug-ins as the IDE, with the tools behind being arm-gcc-embedded toolchain, which is maintained by ARM itself, and has no restrictions. OpenOCD will be the debugger to talk, via adaptors, to the chips (which for this tutorial will be on a development board). I was going to write this with the aid of an Olimex ARM-USB-TINY-H JTAG adaptor and an Olimex H103 development board but these seem to have a long lead time on delivery. So while I'm waiting, I decided I would buy a STM32F4-Discovery Board which incorporates an STLINK adaptor onboard.

To automate the building process I'm going to use make rather than Eclipses internal build system.

To fully use this tutorial, I'll assume you want to be able program ARM based systems and as such willing to stumble your way through the steps to get to the goal. What I mean by this, is that to install some parts and configure them, I will be using a terminal shell. There may be GUI (graphic user interface, such as textedit) tools for these purposes but I won't be using these as they sometime mis-format, try to predict what you want or don't offer the option you want.

The layout for this tutorial is I'll first go through the tools we'll be using in part 1 and how they fit together. In part 2, we'll download and install these on our system. Part 3, we setup Eclipse with these tools using a sample project. By this stage we'll have the basics all laid out. Part 4 is some option extras we can use to enhance our development.

Part 1 - How things fit together and the tools I decided against)

Below are a list of the tools and components we'll be using in our development environment.

First off, we have Eclipse which we'll use as our integrated development environment (the GUI for writing code):

Eclipse [1]

• Our IDE

Eclipse Plug-ins:

CDT [2]

• C/C++ interpreter for Eclipse so it understands the code we write.

GDB Hardware Debugging [3]

• This Plugin allows us to use a GDB tool [4] (debugging tool) to communicate with our debugger, as well as pass it initialising commands and runtime commands before starts its debugging.

Toolchain:

GCC-ARM-Embedded [5]

• The toolchain that includes the ARM based compiler, linker, GDB etc. This toolchain is maintained by the ARM corporation itself. The downside of this toolchain is that it is aimed at ARM Cortex chips and so if not programming this family of chips, another toolchain will need to be used. I blindly suggest compiling GCC from source if you're not using cortex based chips.

Debugger:

OpenOCD [6]

• This is the tool that talks via the adaptor (JTAG, SWD, STLINK etc) to the board. I say board as this can flash to, not just microcontrollers, but also flash chips. It is used as the GDB debugging server as well.

Adaptor/Board Combo:

STM32F4-Discovery [7]

• I'm using this as its cheap and has an integrated STLINK adaptor. It also includes peripherals such as LEDs, USB and a gyroscope.

I will also be using make for automated compiling. I'm using GNU make [8] specifically because it is what is installed with the Development tools on OSX but the Makefiles I assume should work with other distributions of make. I won't be exploring how to install this.

There are a few tools I decided against. These are tools that I either came across when searching for related tools, or were referenced in various tutorials. Upon looking at these in more depth I decided against them for the various reasons mentioned.

GNU ARM Eclipse Plugin [9]

• When I was first looking round at tools to help with the process, I was going to use this for ease of entering compiler settings into Eclipse. I abandoned this idea, firstly because the project is not maintained anymore. Secondly, I went to using make as the build system so didn't ever enter compiler settings into Eclipse anyway.

C/C++ GCC Cross Compiler [10]
• I was going to use this for ease of setting the cross compiler in Eclipse but as with GNU ARM Eclipse Plugin, this behaviour is now being done with make so is not needed within Eclipse itself. If you don't want to use make, this would be a useful.

Zylin CDT embedded plugin [11].

• From what I understand, this is the same as GDB Hardware Debugger but is aimed purely at OpenOCD. It isn't very customisable, it isn't maintained (last updated in 2011) and has no documentation whatsoever.

I also have decided not to use certain toolchains. These are as follows:

Sourcey CodeBench Lite ARM [12]

• It is restricted in code size.

Yagarto [13]

• Its not supported on Linux and from the GNU ARM Eclipse website, it sounds as if it doesn't have support for floating points.

Summon ARM [14]

• This was recommended on the GNU ARM Eclipse website but it is not being developed any more. They recommend GCC Arm Embedded.

GCC compiled from source [15]

• This takes a lot of effort, is hard to maintain and won't have all the patches that are applied downstream in the other toolchains. I still think though, if I was going to compile for non-cortex based chips that this would be the best choice.

CooCox [16]

• This gets its toolchain from Linaro [17] but I don't think it has any advantages over ARM-GCC-Embedded and might even be the same thing. I couldn't find much in-depth information on the Linaro website.

As said in the introduction, I have had to change the development board and adaptor I was hoping to use.

Olimex ARM-USB-TINY-H [18] with Olimex H103 Development Board [19]

• This is what I was planning on using but its going to be quite awhile before it arrives so I went with STM32F4-Discovery. The ARM-USB-TINY-H has the advantage of having JTAG with the ability to be converted to SWD [20] which should be supported by most if not every ARM chip. (The STM32F4-Discovery has SWD for example.)

Part 2 - Installing the components)

Firstly to give credit where its due, I got pointed in the right direction by the "A Light of the World" Blog which has a post on OSX, Eclipse and openOCD [21]. These posts may be good if you know what your doing but it didn't explain what each part does, how they work together and what the configuration of each part means. What really set me off on my journey to find out more, was the lack of mention of the libraries for peripherals which I talk about in appendix B.

So the first step is to download Eclipse. Go to http://www.eclipse.org/downloads/ and download Eclipse Classic. I'm using 4.2.2. Once downloaded and installed, startup Eclipse and goto the Help menu then Install new software. If your behind a proxy, you will need to set this up in Preferences -> General -> Network Connections before hand. Now Select "All Available Sites" from the drop down menu next to 'work with'. The filter bar is actually a search bar. Search for and tick "CDT Visual C++ Support" and "C/C++ GDB Hardware Debugging". Now click next, follow the prompts and install. Thats the eclipse IDE and related plugins installed. Next is OpenOCD.

On Linux based operating systems, OpenOCD should be able to be installed via the package manager. I haven't checked this though as my linux boxes are all production servers. I though am using a Mac running Snow Leopard for my development system. All later versions (and maybe earlier versions) should work with this same process below.

To install OpenOCD with Mac OS, the easiest way is using MacPorts [22]. There is a GUI for installing software via it too (though I prefer using a terminal) and there is plenty of documentation on their website to help out. Using MacPorts will also mean that all the dependencies are downloaded too. This is the same as package management on linux. To install OpenOCD with MacPorts via the Terminal you simply use the command "sudo port install openocd +stlink" from an administrators account. Follow the prompts and it will be installed in no time. Extras are added with +extra such as we've done with STLINK. If you are behind a proxy or firewall, you may want to check appendix A for help if you can't get Macports to work.

If OpenOCD is installed without the STLINK feature, you will get an error stating “Error: The specified debug interface was not found (stlink) The following debug interfaces are available: 1: ft2232”. This can be fixed in Macports by adding +stlink or compiling from source. I only found out later that you could use the +stlink feature in Macports so I compiled from source. To install from source, I used MacPorts to install libusb (sudo port install libusb). Then I set some extra library locations for the linker the install would check the libs MacPorts had downloaded (export CPPFLAGS="-I/opt/local/include" && export LDFLAGS="-I/opt/local/lib"). Then I used the following for my configure settings and did “make && sudo make install”.

./configure --prefix=/opt/local --disable-werror --enable-maintainer-mode --enable-ft2232_libftdi --enable-stlink --enable-arm-jtag-ew --enable-jlink --enable-usbprog --enable-ftdi

I added some extra types of adaptors so I wouldn't need to reconfigure and install any time in the near future.

You can test if OpenOCD works with the STM32F4-Discovery board now by firstly plugging in using the mini usb port and then running “openocd -f board/stm32f4discovery.cfg”. This should change the LED nearest the usb port from red to green assuming all went well. To exit out of this you can force quit using ctr-c.

Now we need to download the toolchain. The latest version of GCC-ARM-Embedded can be downloaded from https://launchpad.net/gcc-arm-embedded. I downloaded a binary so I wouldn't have to compile it. As such, I'm going to install the directory “gcc-arm-none-eabi-4_7-2013q1” in /usr/local/gcc-arm-none-eabi-4_7-2013q1 and then add a symbolic link from /usr/local/gcc-arm-none-eabi so its easier to upgrade in the future. This is done with “ln -s /usr/local/gcc-arm-none-eabi-4_7-2013q1 /usr/local/gcc-arm-none-eabi”. I'm then going to add this path to the environment variables. This is done by editing /etc/profile and adding “export PATH=$PATH:/usr/local/gcc-arm-none-eabi/bin”. What this does is allow the toolchain to be run without needing to be given the entire file path each time but rather just the binary name. This is great for testing on the command line. This can also be done per user in ~/.profile.

At this stage everything is installed. If you don't want to connect everything together and automate with an IDE you can stop here. If you want to test flashing here, I suggest you download the “STM32F4-Discovery Board Firmware Applications Package” which can be found on the ST website. This can be found by going to the ST website > Products > Microcontrollers (from list that comes up when you hover over Products) > STM32 32-bit ARM Cortex MCUs > Under Resources Tab, choose software and click on STM32 Firmware > Find what you need here, in this case STSW-STM32068. In this package is the demonstration code which includes a precompiled binary. To test the download procedure, start OpenOCD with “openocd -f board/stm32f4discovery.cfg”. In a second terminal window, telnet into OpenOCD with “telnet localhost 4444”. [23] We're now connected to OpenOCD and can send commands that affect the chip. To write the demonstration binary to the chip we use the following commands:

reset halt

write_image erase [path to binary]

verify_image [path to binary]

reset run

The path to the binary should be the path to the expanded package we downloaded above then Project > Demonstration > Binary > STM32F4-Discovery_Demonstration_V1.0.0.hex. For example /Developer/ARM/STM32F4-Discovery_FW_V1.1.0/Project/Demonstration/Binary/ STM32F4-Discovery_Demonstration_V1.0.0.hex

If this comes back with no errors, you have successfully flashed the chip. We'll setup GDB debugging later.

Part 3 - Configuring Eclipse IDE and OpenOCD)

We are now ready to configure the different parts so they all work together. We are going to start from the backend and work forwards i.e., start with OpenOCD and work towards eclipse. This part of the setup needs to be done per project so we're going to download a sample program and then keep going.

Download Jeremy Herbert's STM32 Templates from https://github.com/jeremyherbert/stm32-templates/archive/master.zip. Extract this and then copy the folder stm32f4-discovery to your Eclipse workspace directory. From now on, I'll refer to this as our project directory for simplicity. This project should once, compiled and flashed, turn on the LEDs in the order of Green, Orange, Red and Blue with a small period of time between lighting up each. Once each is turned on, there is another delay and then all are switched off and the cycle starts again.

Now, back in Eclipse, goto File > New > Project. In the new window, click the arrow next to the box called C/C++ so that it shows some more options below. Select 'Makefile Project with Existing Code' and then click next. Click the browse button that is next to the text field for Existing Code Location and select the directory that we just copied (which will be in the Eclipse workspace [should be the default location] and then the folder stm32f4-discovery). The toolchain for indexer settings should be set to none.

At this stage, Eclipse likely won't build the project correctly as it can't find our compiler. (This took me quite some time to figure out. I assume Eclipse does not process /etc/profile and so does not get the PATH environment variables we set earlier.) So go to Eclipse's Preferences > C/C++ > Build > Environment and and add a new variable. Make the name 'PATH' and set the value to '${PATH}:path_to_installed_toolchain'. For me this is set to '${PATH}:/usr/local/gcc-arm-none-eabi/bin'. Exit this window and on the main window click on one of the files from the project (if not showing click the grey arrow next to the project name). Now we are able to build/compile the project. This is done with either cmd-B (or equivalent) or selecting Build from the Project menu. You should now find some extra files appear in the project which are the ones we have just created from compiling. These are actually ready to be sent to the chip, we just need to set up Eclipse to do this for us so we don't have to use a terminal window to download.

So we're first going to make a configuration file for OpenOCD. This can also be done with arguments but I'm using a configuration file for simplicity and easy of mobility of moving the project between development systems. So in our project directory create a file called openocd.cfg and place the following text in it. I'll show how to use arguments later.

source [find board/stm32f4discovery.cfg]

This tells OpenOCD we are going to use our STM32F4-Discovery board. This file can be customised to specific boards if there are not configurations supplied by OpenOCD. Extra options can also be placed in this file such as ones affecting debugging, making this potentially much longer than the single line we have.

Thats all the setup we need to do outside Eclipse. So in Eclipse, goto the Run menu and click on Run Configurations. Select C/C++ Application and click the white rectangle with the yellow plus sign to create a new instance. Alternatively right click on C/C++ Application and select new. The right side pane should change. Set the name to stm32f4-discovery Run or the name of your project with the suffix of Run. This is because if you have multiple projects open, all of them will show, so to distinguish between them, we are keeping the project name. Set the C/C++ Application field to the full path of OpenOCD, otherwise it will try to execute a non-existent file in our project. I used /opt/local/bin/openocd. Next check that our project is set for the project. Now change the tab to Arguments. Set the Program Arguments field to

-s openocd.cfg -c "program main.elf verify reset"

I had to use the -s openocd.cfg command as the environment that Eclipse sets up does not seem to find the file automatically. If you did not want to have an openocd.cfg file this is where we can set these up. For our configuration, for example, the above line would change to the one below. In this case there is not much difference but in some configuration the line below will be quite a bit longer.

-f board/stm32f4discovery.cfg -c "program main.elf verify reset"

Make sure the working directory is our project directory, which it should be by default. Next select the Common tab and set this setting to display in the Run Menu. Apply and Close. We now have Eclipse setup to flash the chip when we tell it to run the program. This is fine for basic programs but sometimes, especially for larger programs, we want debugging.

For debugging I'm not going to go through how to do this with the command line, as all the detail given is much easier to understand with a GUI. If you want to do some debugging with the command line, look at STM32F4 Discovery Toolchain for Mac OS X [23] and the GDB and OpenOCD section of the OpenOCD manual. In Eclipse, we firstly need to setup OpenOCD as an external program. This is done by going to the Run menu, then External Tools and then finally selecting External Tools Configuration. Create a new program configuration and name it [Project Name] OpenOCD such as stm32f4-discovery OpenOCD. Set the location to the full path of OpenOCD. For me, this once again, is /opt/local/bin/openocd. Set the working directory to your desired project directory. Set the arguments to -s openocd.cfg or your custom settings from before minus the command to program the chip. On the build tab, turn off build before launch as we do this when we debug, not when we run OpenOCD itself. On the common tab, set this configuration to show in the External Tools menu. Click apply and close.

Next we setup GDB itself. Go to the Run Menu and select Debug Configuration. As we installed GDB Hardware Debugger earlier, we should see this in our left pane. Select it and create a new instance (white rectangle with yellow plus symbol or right click and new). Name the configuration “stm32f4-discovery Debug” and set the project. The next few bits of the configuration have some quirks I'll go through. The application should be the full path to the binary created from the toolchain. This is due to GDB Hardware debugger not having an option of setting the workplace and thus we don't know where it will look if we don't supply a full path. Next on the Debugger tab, set the GDB command to the one from our toolchain. For example /usr/local/gcc-arm-none-eabi/bin/arm-none-eabi-gdb. Use a remote target and set the host name to localhost and the port to 3333. The startup tab is where the real quirk is. Untick Reset an Delay (seconds) and Halt. Then in the field below these put in monitor reset halt. This is because GDB hardware debugger does something weird. If this is not done, you'll will likely get an error like the following screenshot. For those curious I'm using version 7.0.0.201302132326 of GDB Hardware debugger.

We can keep the load image and symbols the same. If you want the program to run straightaway (resume), run till a breakpoint or when the system reaches a certain program counter position then this can beset at the bottom of this tab. On the common tab, set this configuration to show in the debug menu. Apple and close. We now have debugging within Eclipse.

To debug, we first have to start OpenOCD as an external tool. This is done by either pressing the external programs button (shown on right) or from the run menu, external tools and then selecting. External tools, aren't per project so you may need to click on the arrow next to the icon to select the correct external program if the wrong program starts. I had wanted OpenOCD to start automatically when debugging was started but there seems to be no functionality to do this. Plus, as I've since found out, OpenOCD does not shutdown between sessions so this functionality would not be required after the first debug. You can now press the debug button. It will come up with a dialogue asking if you want to change the view to debug mode. Select yes as this view shows us much more relevant information. It can be changed back up in the top right by clicking on the C/C++ button.

A couple os useful tips in this dialog. If OpenOCD is not running, GDB will still start! Next, you can use the symbols in the menu bar to step through the program in different ways. In the pane at the top right (assuming the default view settings), you can view which variables and registers are set and their values. If these say they have been optimised out, try adding -d3 as a compiler setting. The pane in the middle right, says our code in assembly. The pane on the top left allows us to set which program we are controlling with the controls. If the controls are greyed out, make sure you have selected the correct process, for debugging this is GDB. The bottom pane, is also very useful, being the console, this will tell us messages that GDB has outputted which Eclipse hasn't been told to process. We can also use this to see the console for OpenOCD by selecting this process from the top left pane.

This sample program doesn't have much useful information from debugging as most of the time we are in a delay loop. There are numerous other ways OpenOCD has for debugging, but these are more advanced and documented in OpenOCD's manual.

So the sample project we downloaded above is quite a nice simple program for starters. I am going to make a small tutorial on coding with this setup in the near future, but I think this tutorial is quite long enough without a coding tutorial attached. I'll add a link here once I'm done.

Part 4 - Optional Extras)

Within Eclipse there are some extras that will make life easier. I'm not going to go through in detail about these as they are outside the scope of the tutorial but are here for the beginner programmer. First off SVN. Its quite simple to setup, the plugin can be downloaded the same way as the other plug ins we downloaded, by searching for subversive. I recommend this if your ever going to be working on large projects, or projects you want to be backed up, such a university projects. A cheap way of doing this is to use a Raspberry Pi as the server, just don't use a Raspberry Pi if the project is likely to be gigabytes of data as it will be too slow in terms of network performance.

The second extra is Doxygen. Its an inline documentation tool, which if you format your comments correctly in your code, it can automatically produce documentation for you in formats such as PDF, HTML and LaTeX. Its also a standard format so code will be much easier to read by other programmers. For information on how to comment in the correct style, read the Doxygen manual. The manual is much easier to understand than any books or online tutorials I have come across. It can be downloaded separately from http://www.doxygen.nl/download.html and a plugin to Eclipse can be downloaded from http://gna.org/projects/eclox, though this has not been updated since 2009.

Next tip is a speed increase i.e. to stop Eclipse slowing down the machine. This is easily fixed by going to preferences > General > Appearance and changing the theme from Mac OS to Classic. It doesn't look that different but it speeds up dramatically.

Left Original, Right with new theme

Another tip is to fix up some colour issues. As shown in the image above, the default colour scheme is not great at emphasising some elements of code. This issue is a bit more involved to fix. To fix we install a theme plug in. To do this we install the Eclipse Marketplace from the install software utility. Once this has been installed, we can then search for and install Eclipse Color Theme from the marketplace (Help menu -> Marketplace). You can now change the theme in Eclipse's Preferences > General > Appearance > Colour Theme. I didn't find any of these that great so I went to http://eclipsecolorthemes.org/ and found the theme called “XCode inspired theme”. You can then download as a zip and go into the preferences and install from the downloaded zip file.

Conclusion)

Its been an effort to understand all of the tricks to put everything together but its great to have seen how the open source community has built all the tools needed. From code to chip, this can be done without using the expensive products that are purposely crippled and generally only work on a single operating system - Windows. The only real problems I've had, is understanding how everything fitted together due to the lack of documentation, as well as quirks in Eclipse. I hope this tutorial has helped others get to the same understanding and now have the ability to start programming more real life applications. (Not that LED flashing is not a real life application, as my friend is trying to make party lights like this, but its not a very useful application.)

Appendix A – MacPorts behind a Proxy/Firewall:

If you are behind a proxy and/or firewall and using MacPorts, there is a custom fix which you may have to use. Firstly if this is the case, you need to use SVN [18]. If this works, great, but I had problems that the port sync command was failing due to the SVN test it was doing. So inside the file /opt/local/share/macports/Tcl/macports1.0/macports.tcl I had to comment out a few lines. Comment out the lines below "ui_debug $svn_commandline" to two lines above "set needs_portindex 1" but leaving the line "system $svn_commandline" uncommented. Next on the line that starts with "set svn_commandline "$svn_cmd update"" add "--config-option servers:global:http-proxy-host=myproxy.domain --config-option servers:global:http-proxy-port=3128" after "$svn_cmd update". This should get svn and MacPorts working from behind a proxy and firewall like I have. Here is an exert from my macports1.0.tcl for the part effected:

if {$svn_cmd != "" && ([file exists $portdir/.svn] || ![catch {exec $svn_cmd info $portdir > /dev/null 2>@1}])} {

set svn_commandline "$svn_cmd update --config-option servers:global:http-proxy-host=proxy --config-option servers:global:http-proxy-port=3128 --non-interactive ${portdir}"

ui_debug $svn_commandline

#if {

# [catch {

# if {[getuid] == 0} {

# set euid [geteuid]

# set egid [getegid]

# ui_debug "changing euid/egid - current euid: $euid - current egid: $egid"

# setegid [name_to_gid [file attributes $portdir -group]]

# seteuid [name_to_uid [file attributes $portdir -owner]]

# }

system $svn_commandline

# if {[getuid] == 0} {

# seteuid $euid

# setegid $egid

# }

# }]

#} {

# ui_debug "$::errorInfo"

# ui_error "Synchronization of the local ports tree failed doing an svn update"

# incr numfailed

# continue

#}

}

set needs_portindex 1

Appendix B – A quick note about Libraries)

I wanted to say a few things about the libraries/headers for Cortex chips and then STM32 chips. Through stumbling round the internet and eventually giving up, I decided to just ask on StackExchange. I found out that for Cortex-M based (and maybe Cortex-R) ARM chips have a standard header format called CMSIS. You can easily download files from the manufacturers that store information about all the registers and peripherals. I did consider writing some basic code to convert to a standard C header file but thought there must be an easier way. I eventually came across peripherals libraries which I had been unable to find, as coming from AVR and unix C, I called it simply the header files.

On the STM website, these are squirreled away so are quite difficult to find (I said where to find them in the installation section). Once downloaded, not all the files are in the same place. The file we downloaded for this development board for instance has files in:

Libraries > STM32F4xx_StdPeriph_Driver > inc

Libraries > STM32F4xx_StdPeriph_Driver > src

Libraries > CMSIS > include

Libraries > CMSIS > ST > STM32F4xx > include

Libraries > CMSIS > ST > STM32F4xx > source > Templates

for Maths functions,

Libraries > CMSIS > DSP_Lib > Source > Category

Plus in this case ST also give sample drivers for USB in

Libraries > STM32_USB_*

So this makes it quite difficult to find all the correct headers, though most of the time we only want the headers from

Libraries > CMSIS > ST > STM32F4xx > include as this has the basic header with registers etc, and the Libraries > STM32F4xx_StdPeriph_Driver > * headers as these are small utilities to manipulate the registers effectively.

I have no idea of other manufacturers have made the libraries as complex or distributed as ST but I'm guessing its highly likely.

GLOSSERY:

ARM

• Stands for Advanced RISC Machine and is the base architecture for a large amount of micro controllers from a large amount of companies

CDT

• C/C++ Development Tools
  GCC
• Originally was an acronym for GNU C Compiler now stands for GNU Compiler Collection

GDB

• GNU Debugger

GNU

• "a humorous recursive acronym meaning 'GNU's not Unix'" – Wikipedia

GUI

• Graphical User Interface

IDE

• Integrated Development Environment

JTAG

• A general communication protocol for debugging and flashing of ARM chips

LED

• Light Emitting Diode

STLINK

• A communication method for debugging and flashing STM chips

STM32

• A family of ARM chips, manufactured by STMicroelectronics

SVN

• A revision control system. The full name being Apache Subversion.

SWD

• In essence is a newer version of JTAG

Changes:

19^th June 2013:

Added optional extras/tips on speeding up Eclipse and changing the colour scheme.

References:

Part 1)

[1] – http://www.eclipse.org/

[2] – http://www.eclipse.org/cdt/

[3] – https://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/getting-hardware-debuging-working-with-eclipse-and-code-sourcey

[4] - http://www.gnu.org/software/gdb/

[5] - https://launchpad.net/gcc-arm-embedded

[6] – http://openocd.sourceforge.net/

[7] - http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419

[8] - http://www.gnu.org/software/make/

[9]- http://gnuarmeclipse.livius.net/wiki/Main_Page

[10] –

[11] - http://opensource.zylin.com/embeddedcdt.html

[12] - http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/

[13] - http://www.yagarto.de/

[14] - https://github.com/esden/summon-arm-toolchain

[15] - http://gcc.gnu.org/

[16] – http://www.coocox.org/

[17] – http://www.linaro.org/

[18] - https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY-H/

[19] - https://www.olimex.com/Products/ARM/ST/STM32-H103/

[20] - https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-SWD/

Part 2)

[21] - http://salvatoremenendez.blogspot.com.au/2011/08/mac-os-eclipse-openocd-stm32-arm-cortex.html

[22] - http://www.macports.org/

[23] – http://spin.atomicobject.com/2013/01/18/stm32f4-discovery-toolchain-mac-os-x/

Part 3)

[24] – http://stackoverflow.com/questions/2427011/what-is-the-difference-between-elf-files-and-bin-files

Appendix A)

[25] – https://trac.macports.org/wiki/howto/SyncingWithSVN

Other Resources used:

http://www.triplespark.net/elec/pdev/arm/stm32.html