Configuring Eclipse + OpenOCD + GCC to Debug NativeSample

Stefan Schmidt already made an excellent (and gray-hair-reducing) blog entry on getting Eclipse/OpenOCD configured to work with the Porting Kit and GCC. All the hard work has been done by him, so a very big thanks to begin with. That said, his recommended configuration didn't work right away for me when trying to get the NativeSample application working with GCC and an LPC2478 board. As such, I thought it was worthwhile to put here the settings *I* had to use to get the debugging process working for me, just to save someone else the headaches if they have similar requirements (in my case, getting NativeSample working on an LPC2478 based board using the internal RAM/Flash).

Requirements

• An ARM Toolchain (Stefan recommended Raissonance's free toolchain, but I'm using the also free CodeSourcery G++ Lite Q3 2007, since this is the same GCC toolchain used by the PK Team)


• OpenOCD (I'm using 0.1.0)


• Eclipse IDE (I'm using Eclipse IDE for C/C++ Developers)


• Zylin-embedded CDT (installed from within Eclipse via Software Updates: http://www.zylin.com/zylincdt)
  
• A JTAG debugging device compatible with OpenOCD (while I own many, in this case I'm using Olimex's ARM-USB-OCD since it's affordable, convenient, and easy to find online).


• Obviously some sort of ARM7/9 development board (I'm using an Olimex P2478 STK in this case since I had one laying around, and it is a good fit for the NETMF)

Installation

The first step is obviously to install your ARM Toolchain, Eclipse, and OpenOCD, and of course the Porting Kit if it isn't already installed. For reference sake, the following are the default folders on my own installation:

CodeSourcery G++ Lite: C:\Program Files\CodeSourcery\Sourcery G++ Lite
Eclipse: C:\Program Files\Eclipse
OpenOCD: C:\Program Files\openocd-r717
Porting Kit: E:\MicroFrameworkPK_v3_0

Install Zylin Embedded CDT

To do any sort of debugging, you will need to install the freely available Zylin Embedded CDT.

1. Load Eclipse


2. Select Help -> Software Updates ....


3. Click on the Available Software tab


4. Click the Add Site... button and enter the following url: http://www.zylin.com/zylincdt

You should now be able to install Zylin Embedded CDT which is required for the debugging process. Unfortunately, since I already have it installed I can't give exact step-by-step instructions on this, but it should be fairly obvious where to find it on the list of available updates. You can google Eclipse's software update utility if you are stuck, or see Stefan's blog since I believe he also touches on this.

Create a New Project in Eclipse

1. Open a command prompt and go to the folder where the Porting Kit is installed:
   ex.: "E:\MicroFrameworkPK_v3_0"


2. Run "setenv_gcc.cmd" passing in the folder where your arm toolchain is located:
   ex.: "setenv_gcc.cmd c:\progra~1\CodeSourcery\Source~1"


3. Launch Eclipse from the command prompt:
   ex.: "c:\progra~1\Eclipse\eclipse.exe"


4. Create a new C++ Project in Eclipse


5. Give the project the same name as the folder where the PK in installed:
   ex.: "MicroFrameworkPK_v3_0"


6. Set the working folder to be one level higher than the porting kit installation folder:
   ex.: "E:\"

Configure the Build Settings

1. Select the project in the "Project Explorer" window (on the left by default), and select Project -> Properties in the menu


2. Click on the "C/C++ Build" item in the treeview


3. Click the "Manage Configurations ..." button and create a new configuration named "LPC2478 Debug (Flash)" or something similar. Set it to active and click OK.


4. In the "Builder Settings" tab, add the following settings:
   Build Command: "msbuild.exe"
   Build Directory: "${workspace_loc:/MicroFrameworkPK_v3_0/Solutions/LPC2478}"
   Note: the folder name will change depending on what name you entered in the Solution Wizard


5. In the "Behaviours" tab, check Build (Incremental Build) and add the following:
   "dotNetMF.proj /t:build /p:flavor=debug;memory=flash;platform=LPC2478"
   Note: This is different than Stefan's suggestions since I am using Flash and not RAM

Configure OpenOCD as an External Tool

1. Select the Run -> External Tools -> External Tool Configuration ... menu entry


2. Select "Program" in the left-hand treeview and click the "New launch configuration icon in the top left corner", and name the new tool configuration "OpenOCD (ARM-USB-OCD)"


3. On the Main tab add the following settings:
   Location: C:\Program Files\openocd-r717\bin\openocd-ftd2xx.exe
   Working Direction: C:\Program Files\openocd-r717\bin\
   Arguments: -f scripts\lpc2294\lpc2xxx_armusbocd.cfg


4. Go to the Common tab and in Display in favorites menu box, check "External Tools". This will add OpenOCD to your favorites menu where it can more easily be launched.


5. If you want the project to build every time you launch OpenOCD go to the Build tab and check Build before launch.

Configure GDB (GCC Debugger)

1. Select the Run -> Debug Configurations menu


2. Select "Zylin Embedded debug (Native)" in the left-hand treeview, and create a "New Launch Configuration" using the appropriate icon in the top left corner.


3. Name it "LPC2478 NativeSample" or something similar


4. In the Main tab, select the C/C++ Application textbox and enter:
   E:\MicroFrameworkPK_v3_0\BuildOutput\ARM\GCC4.2\FLASH\debug\LPC2478\bin\NativeSample.axf
   Note: This folder may change depending your how you have configured your build, and the name you gave your project in the Solution Wizard, etc.


5. In the Debugger tab, set the GDB Debugger textbox to:
   C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin\arm-none-eabi-gdb.exe


6. In the Commands tab, add the following the the 'Initialize' commands box:
   target remote 127.0.0.1:3333
   monitor reset
   monitor sleep 500
   monitor poll
   monitor soft_reset_halt
   monitor arm7_9 force_hw_bkpts enable
   break PreStackEntry
   load
   continue
   NOTE: The settings above will connect to the GDB server, enable hardware breakpoints, and set the first breakpoint at PreStackEntry. This is different than Stefan's suggestions, since we will need to debug in Flash (not RAM) if we are only using the internal sram/flash available on the LPC2478. It's worth mentionning that when debugging in FLASH you are limited to two hardware breakpoints (I believe there is no limit in SW debugging). If you wish to use software breakpoints, you simply need to change the appropriate line from force_hw_bkpts to sw_bkpts.

Test it out

Once everything is configured, there are three main steps you will need to do to start debugging (assuming you have the JTAG device properly installed and connected to the board, and everything is powered up).

1. Build the project using the configuration settings we added in the first step above. This can easily be done using the Build icon in the IDE, as seen below. You will need to examine the Console tab on the bottom of the screen (you may need to select it) to see if there are any errors, etc., since all the output that you would normally see in the command prompt when running MSBuild will appear there.
   



2. The the build above was succesful then ... pat yourself on the back, and Start OpenOCD using the External Tools Icon:
   



3. Finally, if OpenOCD is running, you can start debugging using the Debug Icon:
   

This should be everything you need to set up to start debugging (though I'm sure, like me, there may be other little obstacles you need to figure out depending on your own setup/toolchain, etc.). To warn you in advance, I've often had some odd problems with OpenOCD, and you will likely need to adjust the configuration script ('scripts\lpc2294\lpc2xxx_armusbocd.cfg' in this example) to adjust the jtag_speed, etc., but that's another topic and there are resources on the web that can help you learn how to properly use and configure both OpenOCD and GDB. The above, along with Stefan's excellent blog entry, should at least get you moving in the right direction, though.

OpenOCD Config Script (Just in case)

If it does help someone, here is the config file I ended up using to get OpenOCD working for me with the LPC2478 (which uses a 12MHZ crystal ... fairly common with NXP ARM7 chips):

#daemon configuration

telnet_port 4444

gdb_port 3333



# tell gdb our flash memory map

# and enable flash programming

gdb_memory_map enable

gdb_flash_program enable



#interface

interface ft2232

ft2232_device_desc "Olimex OpenOCD JTAG A"

ft2232_layout "olimex-jtag"

ft2232_vid_pid 0x15BA 0x0003

jtag_speed 9

jtag_nsrst_delay 200

jtag_ntrst_delay 200





#use combined on interfaces or targets that can't set TRST/SRST separately

reset_config trst_and_srst srst_pulls_trst



#jtag scan chain

jtag_device 4 0x1 0xf 0xe



#target configuration

daemon_startup reset



#target  

target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

run_and_halt_time 0 30



working_area 0 0x40000000 0x4000 nobackup



#flash configuration

#flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum

flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 12000 calc_checksum



# For more information about the configuration files, take a look at:

# http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger

#

And the Final Result ...

Here is a screenshot of the debugging in action:

Precompiled GCC Toolchains for the Porting Kit

I have been trying to get GCC to work with the .Net Micro Framework Porting Kit (PK), but unlike the commercial compilers that are supported for the PK (MDK, etc.), there are five dozen different ways to build a GCC/ARM toolchain.

In .NET Micro Framework Porting Kit V3.0 with GCC Support?, Stefan Schmidt had suggested using Raisonance's free ARM toolchain, since a none EABI compiler is required. I had downloaded it, and tried it out, but I also asked the NETMF support team which toolchain they are using internally, since it will likely make any support inquiries easier, and save me a headache as well. Apparently, they are using the (also free) Sourcery G++ Lite toolchain from CodeSourcery. I opted to use the older Q3 2007 release (reference in the previous link), since the newer releases use GCC 4.3, whereas the porting kit was tested to work with 4.2.

Once I can get the NativeSample project up and running, I'll post a tutorial on how to properly configure Sourcery G++ Lite with the PK.