Using Eclipse CDT with GCC-ARM toolchain allows choices:
This IDE setup provides very similar environment to TI Code Composer Studio.
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.
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.
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:
(GNUARM and WinARM are considered dead)
Some say that codesourcery produces the leanest code, but its important to have alternatives to Mentor Graphics.
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.
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.
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
Add this startup file to your project
TrueSTUDIO linker script works for GNU ARM toolchains.
In the case of STM32L1xx standard library, look in
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.
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
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.
GCC for ARM predefines
Use that for conditional compiling byte order.
To list all predefined macros:
arm-none-eabi-gcc -dM -E - < /dev/null | sort
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
For smallest program size: Project properties → C / C++ Build → Settings:
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.
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
arm-none-eabi-gdb <project>.elf, the following commands in
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 must have
pc is start address
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.
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.
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.
Zylin Embedded Debug (Native)
monitor resetin console tab, then hit single-step button. (or
mon reset haltfor openocd)
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.
For GIT integrated into Eclipse, try EGit.