OpenOCD Troubleshooting: Can’t Find File.cfg

From TinCanTools
Jump to: navigation, search

You attempt to run OpenOCD and it exits immediately with a warning:

Can't find [file].cfg

OpenOCD has failed to find one or more config files. This guide will help you diagnose and correct the problem.

Can't Find openocd.cfg

If you see this message, you have likely run OpenOCD with no command line arguments. OpenOCD requires at least one config file to tell it how to communicate with your hardware. If you don't specify any, it searches for openocd.cfg. However, OpenOCD doesn't provide openocd.cfg by default. Even if it did, it wouldn't do any good because it wouldn't be tailored to any particular hardware.

Find the config files with your hardware. If you have compiled OpenOCD from source, they are most likely located in your OpenOCD directory, at tcl/interface, tcl/board, or tcl/target. Run OpenOCD again, using the -f switch to specify the path to each config file. For example:

openocd -f interface/flyswatter2.cfg -f board/hammer.cfg

If you know how to write your own config files you can also write your own openocd.cfg and place it in the same directory as the OpenOCD binary, but this is not necessary. See the links at the bottom of this page for more information on config files.

Can't Find a File Specified with -f

You run OpenOCD with the -f switch and OpenOCD can't find the file. For example, suppose you ran OpenOCD as above and saw the following error:

Can't find board/hammer.cfg

Make sure the config file exists and the path you specified is correct. If the file is present on your computer, make sure OpenOCD can find it from one of its default search paths. See OpenOCD Config File Paths for information on how OpenOCD finds config files.

Can't Find Another Config File

OpenOCD prints a runtime error stating that it can't open a config file you didn't specify with -f. For example, suppose you ran OpenOCD as follows:

openocd -f interface/flyswatter2.cfg -f board/hammer.cfg

…and saw this error:

Runtime Error: embedded:startup.tcl:58: Can't find target/samsung_s3c2410.cfg

So why was OpenOCD looking for samsung_s3c2410.cfg? The hammer.cfg file contains the line:

source [find target/samsung_s3c2410.cfg]

…to load the config file for the Hammer's CPU. When OpenOCD parses hammer.cfg it also searches for target/samsung_s3c2410.cfg, just as if you had specified it with the -f switch.

If OpenOCD fails to find a file specified in another config file, make sure the file path is valid for OpenOCD's search paths. You may need to specify an additional search path with the -s switch. See OpenOCD Config File Paths for more information on search paths and the -s switch.

More Information

Running OpenOCD on Windows

Running OpenOCD on Linux

OpenOCD Config File Paths

OpenOCD Config File Paths

From TinCanTools
Jump to: navigation, search

Config File Basics

Each time you use OpenOCD you will need to configure it by passing it paths to configuration files. In the OpenOCD 0.4.0 release, these files are found in openocd-0.4.0/tcl and its subdirectories. From the tcl directory, the configuration file for the Flyswatter is at interface/flyswatter.cfg. The file for the TinCanTools Hammer is at board/hammer.cfg. If your copy of OpenOCD includes support for the Flyswatter2, its config file is at interface/flyswatter2.cfg.

When you start OpenOCD, you tell it to use the config files for your hardware with the -f switch, like this:

openocd -f path_to/cfg_file [-f path_to/other_cfg_file]

For example, suppose you want to run OpenOCD for the TinCanTools Flyswatter2 and Hammer board. The current directory contains the OpenOCD executable and the board, interface, and target directories provided with the OpenOCD source. You would type:

openocd -f interface/flyswatter2.cfg -f board/hammer.cfg

If you do not supply any config files with the -f switch, [[[OpenOCD]] attempts to load a config file called openocd.cfg. This file is not supplied by default; you must write or supply it yourself. If OpenOCD cannot find this file, it prints an error and exits.

Default Locations for Config Files

The OpenOCD source comes with config files in three different locations.

  • openocd/tcl/target
  • openocd/tcl/interface
  • openocd/tcl/board

When you compile OpenOCD, the make install command copies the config files in three additional locations.

  • /usr/local/share/openocd/scripts/target
  • /usr/local/share/openocd/scripts/interface
  • /usr/local/share/openocd/scripts/board

If you compile OpenOCD for Windows using Cygwin, these paths are within Cygwin. The full Windows paths would be C:\cygwin\usr\local\share\openocd\scripts\target and so on.

Searching Additional Directories: The -s Switch

You can tell OpenOCD to look for config files in a directory using the -s command line switch, like this:

openocd -s path/to/dir_with_cfg_files -f cfg_file.cfg

The search path can be absolute, or relative to the current directory. For example, suppose you have just finished compiling OpenOCD. The openocd executable is located in openocd/src and the config files are in openocd/tcl. You want to run OpenOCD with the Flyswatter and Hammer board. From openocd/src, you run OpenOCD as follows:

openocd -s ../tcl -f interface/flyswatter.cfg -f board/hammer.cfg

File Locations

When OpenOCD searches for a config file, it looks in the following locations, in order:

  1. The current directory
  2. Any additional directories you supply with the -s switch
  3. Any additional directories added with OpenOCD's add_script_search_dir command
  4. Linux/Cygwin Only: The hidden directory .openocd in your home directory
  5. Linux/Cygwin Only: The directory /usr/local/share/openocd/scripts (created in /usr/local/share when you compile OpenOCD)

If the config file exists in more than one location, OpenOCD uses the first one found. This is especially important if you have more than one copy of the same config file on your computer. If you need to change a config file, make sure your place it where OpenOCD will use it in preference to other versions of the file.

On Windows the last two locations will only be available if you run OpenOCD from within Cygwin.

Loading Config Files from Other Config Files

Some config files load other config files. For example, the config file for the Hammer, hammer.cfg, contains this line:

source [find target/samsung_s3c2410.cfg]

When OpenOCD loads hammer.cfg, it also tries to load target/samsung_s3c2410.cfg and gives an error if it cannot find this file. You need to ensure that OpenOCD can find this file from one of its search directories. If you have your config files in the default openocd/tcl directory, the executable in openocd/src, and you run OpenOCD like this:

openocd -s ../tcl/board -s ../tcl/interface -f flyswatter.cfg -f hammer.cfg

…then OpenOCD won't find target/samsung_s3c2410.cfg. It searches for /tcl/board/target and /tcl/interface/target but doesn't find either. However, if you run OpenOCD like this:

 openocd -s ../tcl -f interface/flyswatter.cfg -f board/hammer.cfg

…then it looks looks for tcl/target/samsung_s3c2410.cfg and finds the file.

Lsusb

From TinCanTools
(Redirected from Lsusb)
Jump to: navigation, search

The lsusb command provided in Ubuntu Linux provides information about USB devices connected to your computer. To use lsusb, open a terminal window and type:

sudo lsusb

This will display a list of all USB devices connected to your computer. Look for the hardware you want to use with OpenOCD. For the Flyswatter you should see something like this:

Bus 002 Device 006: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC

The bus number and device number will likely be different, but take note of them. Now get more information about the device by typing:

sudo lsusb -v -s [BUS_NUMBER]:[DEVICE_NUMBER]

For example, if you had seen the output listed above, you would type:

sudo lsusb -v -s 002:006

Scroll up through the information about your hardware. For the original Flyswatter, you should see something like this:

 idVendor           0x0403 Future Technology Devices International, Ltd
 idProduct          0x6010 FT2232C Dual USB-UART/FIFO IC
 bcdDevice            5.00
 iManufacturer           1 TinCanTools
 iProduct                2 Flyswatter
 iSerial                 3 FS000000

Pay careful attention to the values following idVendor, idProduct, iProduct, and iSerial. If those values for your hardware don't match the values listed above, OpenOCD won't recognize the Flyswatter.

File:lsusb.png

lsusb -v Showing Flyswatter Info

You should see similar output for the Flyswatter2, except that the iProduct and iSerial values are different:

 idVendor           0x0403 Future Technology Devices International, Ltd
 idProduct          0x6010 FT2232C Dual USB-UART/FIFO IC
 bcdDevice            7.00
 iManufacturer           1 Tin Can Tools
 iProduct                2 Flyswatter2
 iSerial                 3 FS200000

If lsusb doesn't show the values you expect for your hardware, there may be a problem with the hardware itself or with your USB drivers.

Libftdi vs FTD2XX

From TinCanTools
Jump to: navigation, search

LibFTDI and FTD2XX Licensing

FTD2XX is a proprietary USB driver library developed by Future Technologies Devices International (FTDI), available from http://www.ftdichip.com. LibFTDI is an alternative open source USB driver library available from http://www.intra2net.com/en/developer/libftdi/.

FTD2XX is a closed-source library. A program licensed under the GNU General Public License (such as OpenOCD) cannot be distributed in binary form if linked to FTD2XX during compilation. LibFTDI is licensed under the GNU Lesser General Public License v2.1. Information on LGPL v2.1 is available at http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.

Speed Comparison with OpenOCD

The following tests were performed with OpenOCD v0.4.0, linked with libFDI and FTD2XX, following the instructions on this wiki. All tests were performed with the TinCanTools Hammer and Flyswatter. Each test consisted of 200 immediately consecutive commands. Commands used were register dumps ('reg' command, 200 times) and single steps ('halt', then 'step' command 200 times, then 'resume'). Commands were sent to OpenOCD through scripts via a telnet client. Each test was performed 10 times; the results below show the average time over 10 tests.

The OpenOCD source was modified to report time elapsed after each command, starting from the first command received. Time was reported with the gettimeofday() function defined in sys/time.h on Linux and redefined for Windows in the OpenOCD source file replacements.c. Note that gettimeofday() does not use a high-precision timer, and very small differences in execution time below do not necessarily reflect a meaningful difference in actual performance. The source modification also disabled the output of the 'reg' command, to prevent the time required to write the contents of 54 registers to the screen (nontrivial on Windows) from eclipsing the time required for OpenOCD to execute the commands.

Note that the data below is only useful got comparing libFDTI and FTD2XX, not to compare each drivers' performance on Windows vs Linux. The Ubuntu installation used in this test was installed inside Windows, which slows it down considerably.

Windows Test

Windows tests were performed on Windows XP64 SP3. These tests show a 13% faster execution time for the 'step' command with the proprietary FTD2XX library. Both performed roughly equally with the 'reg' command.

Test LibFTDI FTD2XX
reg 413 ms 409 ms
step 14048 ms 12384 ms

Linux Test

Linux tests were performed with Ubuntu 10.04 LTS installed inside Windows. These tests show the 'reg' command as 9% faster with the proprietary FTD2XX library. The 'step' command performed similarly with both libraries.

Test LibFTDI FTD2XX
reg 3345 ms 3074 ms
step 49769 ms 50780 ms

LPC2214 Eclipse and GDB

From TinCanTools
Jump to: navigation, search

GDB, the GNU Project Debugger is a debugging tool provided with the GNU Compiler Collection (GCC). GDB allows you to stop and start a running program, examine its functioning, and make changes.

The Eclipse IDE is a multi-language integrated development environment which can be used to develop, install, and debug embedded applications.

This guide will walk you through installing Eclipse and configuring it for embedded development, installing a GCC toolchain to compile programs for ARM processors, and finally compiling and debugging a simple program in GDB. These instructions were written for Ubuntu 12.04 LTS.

Install the ARM EABI Toolchain

To compile programs for ARM processors you will need a cross-compiler and toolchain. This guide will compile and install the ARM EABI toolchain via a script created by James Snyder.

Step 1: Download the Script via Git.

Git is version-control software used for managing code and assets during software development. Here we use it to download Snyder's script. In a terminal window, type:

sudo apt-get install git

When the install finishes, type:

cd ~
git clone https://github.com/jsnyder/arm-eabi-toolchain.git

download jsnyder script.png

This will create a folder called arm-eabi-toolchain in your Home directory, containing the makefile script we need.

Step 2: Install Dependencies.

The makefile requires several utilities and libraries to compile and install correctly. In a terminal window type (all on one line):

sudo apt-get install curl flex bison libgmp3-dev libmpfr-dev texinfo 
libelf-dev autoconf build-essential libncurses5-dev libmpc-dev

WARNING: Don't try to copy and paste the text above into your terminal window! If you want to copy and paste so you don't miss anything, use the line below:

sudo apt-get install curl flex bison libgmp3-dev libmpfr-dev texinfo libelf-dev autoconf build-essential libncurses5-dev libmpc-dev

Select the text in your browser, press Ctrl+C, then right-click on the terminal window and select Paste. Press Enter to install.

jsnyder deps.png

You can find this list of dependencies in Snyder's readme file, installed at /home/USERNAME/arm-eabi-toolchain/readme.md.

Step 3: Install libexpat.

Before we compile the toolchain we need to install one more library. In the terminal window, type:

sudo apt-get install libexpat-dev

Without this library, the toolchain will compile successfully but the debugger won't be configured to load software to the correct place in the board's memory. You may see an error stating that libexpat-dev has an unmet dependency: the wrong version of another library libexpat1. In that case, use this instead to install with the correct version of libexpat1:

sudo apt-get install libexpat1=2.0.1-7.2ubuntu1 libexpat-dev

Step 4: Execute the Makefile.

Navigate to /home/USERNAME/arm-eabi-toolchain and execute the makefile with sudo make install-cross:

cd ~/arm-eabi-toolchain
sudo make install-cross

jsnyder install.png

The script downloads the source code for the toolchain, compiles them, and installs.

Step 5: Wait.

The makefile will take a long time to run – possibly upwards of an hour. When it finishes, check back over the last several lines in the terminal window to make sure there were no errors. If everything went correctly, you should now have a folder in your Home directory called arm-cs-tools.

Step 6: Add the Cross-Compiler Tools to PATH.

In a terminal window, navigate to /etc and open the file called environment in a text editor. We'll use gedit, the text editor installed by default on Ubuntu.

cd /etc
sudo gedit environment

The first line of environment is a list of directories Ubuntu uses to search for executables. Add the following text to the beginning of the list, right after the open-quote:

$HOME/arm-cs-tools/bin:$HOME/arm-cs-tools/libexec/gcc/arm-none-eabi/4.7.3:

environment arm cs tools.png

Save the file and exit. Now back in the terminal window, update your PATH by typing:

source /etc/environment

The directories containing the cross-compiler executables should now be in your PATH. You can verify by typing:

echo $PATH

To make sure Ubuntu can find the cross-compiler, type:

arm-none-eabi-gcc --version

You should see a printout with version information.

path arm cs tools.png

Remember this Later…

You may get a "Command not found" error when trying to run part of the toolchain. When you restart your computer, your path may change. You can fix this by resetting PATH from the file you edited earlier:

source /etc/environment

Also, the sudo command changes your PATH. It won't matter for the rest of this guide, but if you ever need to access part of the toolchain with sudo you can do so like this:

sudo env PATH=$PATH command_here

Install and Configure Eclipse

Step 1: Install Java.

Eclipse can be used to develop programs for multiple languages, but the Eclipse software itself runs in Java. If you're not sure whether you have Java installed already, open a terminal window and type:

java --version

If you have a Java Runtime Environment (JRE) installed, you will see the name of the distribution and a version number. Note for users unfamiliar with Java development: The Java Runtime Environment (JRE) and the Java plugin that runs applets in your web browser are two different things. What we need is the JRE.

To install the JRE, type in a terminal window:

sudo apt-get install openjdk-7-jre

Press 'Enter' on your keyboard, then 'y' when prompted.

install openjdk.png

Once installation completes you can verify that everything installed correctly by typing java –version again.

java --version

Step 2: Download Eclipse.

Go to http://www.eclipse.org/downloads in your browser. Download the Eclipse IDE for C/C++ Developers. There are different versions for 32- and 64-bit Linux; download the one appropriate to your computer's operating system.

Open the archive and extract it to your Home folder.

Doubleclick the eclipse executable to start the IDE. You should see this loading screen:

eclipse loadscreen.png

Next Eclipse will prompt you to select a workspace:

eclipse workspace.png

This will create a new directory to store your Eclipse projects. This guide will assume you use the default /home/USERNAME/workspace. Click OK.

Step 3: Install the Eclipse CDT Plugin.

You should now be at the Eclipse welcome screen.

eclipse welcome.png

At the top of the window, go to Help > Install New Software… to bring up the Install window. In the text bar at the top of the window, enter the following URL:

http://download.eclipse.org/tools/cdt/releases/kepler

eclipse installcdt.png

You should see two options: CDT Main Features and CDT Optional Features. Click the checkboxes next to each and click Next to go to a list of features to be installed:

eclipse installcdt2.png

Click Next again to install.

Step 4: Install Cross Development Tools.

In the Eclipse window, go again to Help > Install New Software… This time in the text bar at the top of the window, enter:

http://gnuarmeclipse.sourceforge.net/updates

eclipse installcross.png

Check the box net to CDT GNU Cross Development Tools, hit Next, and then Next again to install.

Create a Simple Eclipse Project

Step 1: Download LPC2214_LEDblink.

LPC2214_LEDblink is a simple program that will repeatedly blink the red LED banks on the UNI-DS6. Download it here:

Download LPC2214_LEDblink

Open the archive and extract the contents to your Home folder.

Step 2: Create a New Eclipse Project.

In Eclipse, look at the menu at the top of the screen. Select New > Makefile Project with Existing Code. The New Project window should appear. Configure your new project as follows:

  • Give the project a name.
  • In Existing Code Location, browse to /home/USERNAME/LPC2214_LEDblink and click OK.
  • Check C under Languages.
  • Under Toolchain for Indexer Settings, select Cross GCC.

eclipse newproject.png

Click Finish to create your project. You can now view your project heirarchy in the Eclipse Project Explorer window (on the left in the picture below).

eclipse justmadeproject.png

Step 3: Set your Project's PATH Variable.

Earlier, we set the PATH variable so your operating system could find the ARM EABI toolchain executables. When Eclipse creates a new project it imports your PATH and uses it by default. Just one problem: Eclipse can't parse the $HOME variable in your PATH, so you'll have to edit your project settings.

In the Project Explorer window, left-click on the top level of your project to select it. Then in the menu at the top, go to Project > Properties. Expand C/C++ Build and select Environment.

eclipse setpath.png

Select PATH and click Edit to bring up the Edit Variable window. Add the following text to the beginning of the text box:

/home/USERNAME/arm-cs-tools/bin:/home/USERNAME/arm-cs-tools/libexec/gcc/arm-none-eabi/4.7.3:

…but replace USERNAME with your Linux username. Don't use $HOME or the tilde (~) symbol in place of /home/USERNAME.

eclipse setpath2.png

Click OK. Then back in the Properties window, click Apply then OK.

Step 4: Set your Project's Debug Configuration.

Back on the Eclipse main screen, click on the top level of your project again to select it. Then in the top menu go to Run > Debug Configurations. A new window should appear. In the menu on the left, expand GDB Hardware Debugging and select ledblink Default (or whatever you named your project).

eclipse setdebugger.png

To the right, select the Debugger tab.

  • Change GDB Command to arm-none-eabi-gdb. (It should say gdb by default.)
  • Change Port number to 3333.

eclipse setdebugger2.png

Now go to the Startup tab.

  • Uncheck Reset and Delay.
  • Uncheck Halt.
  • In the textbox beneath Reset and Delay and Halt, type the following:
monitor halt
monitor reset init
  • Make sure the settings under Load Image and Symbols look like the image below. (You shouldn't need to change anything.)

eclipse setdebugger3.png

Click the Apply button, then click Close.

Step 5: Build your Project.

In the top menu, go to Project > Build All. If the project compiles successfully you should see new object files appear in the Project Explorer.

eclipse built.png

Load and Debug the Program with GDB

For this step, you will need a Flyswatter2, OpenOCD and a configuration file for the lpc2214 chip. If you haven't already installed OpenOCD and downloaded lpc2214.cfg, go to Flyswatter2 LPC2214 How To and follow the instructions there.

Step 1: Start OpenOCD.

Connect your Flyswatter2 and mikroBoard / UNI-DS6. Open a terminal window and run OpenOCD as described in the Flyswatter2 LPC2214 How To.

cd ~/openocd-bin
sudo ./openocd -f interface/flyswatter2.cfg -f target/lpc2214.cfg -c init -c "reset init"

ocdstartup lpc2214.png

Step 2: Start GDB and Load the Program.

Back in Eclipse, select the top level of your project. In the top menu go to Run > Debug Configurations. Expand the GDB Hardware Debugging Tab and select ledblink Default. You should now be back where you were when you set your debug settings earlier.

Note: The C/C++ Application text area may be blank. If it is, click the Search Project… button and select main.out.

eclipse setdebugger.png

This time, click Debug. You will be prompted to switch to a Debug perspective. Click Yes.

eclipse switchperspective.png

This will change Eclipse's layout to show debugging information. (Later you can get back to the old perspective from the top menu: Window > Open Perspective > C/C++.) The Debug perspective looks something like this:

eclipse debugperspective.png

Go back to your OpenOCD terminal window and make sure it reset properly. You should see something like this:

eclipse gbd openocd connect.png

Step 3: Resume the Program.

The LEDblink program should now be in your board's flash memory. However, nothing should be happening yet. In the Eclipse top menu, go to Run > Resume. You should see the red LED banks on the UNI-DS6 blink on and off.

This may not work on the first try because of hardware issues with the UNI-DS6. If the LEDs don't blink but you don't see any errors in Eclipse, try reloading the program:

  • Terminate the program. (Top menu in Eclipse: Run > Terminate.)
  • Don't restart OpenOCD or rest the UNI-DS6.
  • Build and load the program again, as in Step 2 above.

If that fails, try restarting the UNI-DS6:

  • End your debugging session. (Top menu in Eclipse: Run > Disconnect.)
  • Shut down OpenOCD.
  • Turn the power switch on the UNI-DS6 off and then on again. LEDblink is still in flash memory, so the LED blanks should start blinking immediately on startup.
  • Try again from Step 1: Start OpenOCD.

Be sure to try both solutions. The first may work when the second fails, or vice versa.

Using GDB in Eclipse

Eclipse provides a GUI wrapper around the most common GDB commands. Normally you would run GDB commands from a terminal window, but you can perform several GDB actions through Eclipse.

Suspend and Resume the Program

To pause the program, use the top menu, Run > Suspend. Try this and you should see the LEDs on the UNI-DS6 stop flashing. To resume, use Run > Resume or press F8 on your keyboard.

Insert a Breakpoint

A breakpoint suspends the program each time it reaches a particular line of code. Breakpoints allow you to read the contents of memory before the program can change it, or find errors by verifying that the program runs correctly up to a particular point.

First suspend the program as above (Run > Suspend). In the code view for main.c at the center left of the Eclipse screen, click to place your mouse cursor in line 79. Line 79 should read:

delay_ms(150);

In the top menu, select Run > Toggle Breakpoint. Alternatively you can press Shift+Ctrl+B on your keyboard. A blue dot should appear to the left of Line 79.

eclipse breakpoint.png

Resume the program (Run > Resume or F8). The program will run until it reaches the breakpoint and then suspend automatically. You should see the LEDs on the UNI-DS6 flash off once, then come back on and stay on. Because this breakpoint is in the middle of a loop that never terminates, you can keep repeating this indefinitely. Each time you resume the program, the lights should flash off once and then come back on.

To remove the breakpoint, select Run > Toggle Breakpoint or press F8 again. Do that now.

Check the Value of a Variable

While the program is suspended, Eclipse shows you the current value of variables. Insert a new breakpoint at Line 57. Just as before, suspend the program (Run > Suspend), place your cursor in Line 57 and select Run > Toggle Breakpoint or press F8. Line 57 is a for loop that forces LEDblink to delay between flashes:

for (j = 0; j < 4000; j++ );

Insert a new breakpoint at Line 57. Resume the program with Run > Resume or F8. This breakpoint is at a head of a nested loop within another for loop:

for (i = 0; i < ms; i++ )
for (j = 0; j < 4000; j++ );

So each time the the breakpoint is reached, the value of i should increase by 1. Look at the value of i in the Variables window at the upper right.

eclipse debugvar.png

Resume the program again, and the value of i should increase by 1.

Check the Value of a Memory Address

Unfortunately we can't use the Eclipse GUI to read the values that turn the LEDs on and off. However, we can get those values from memory directly using GDB text commands. Remove the breakpoint at Line 57 and put a new one back at Line 79 where we had it earlier (delay_ms(150); in the middle of the while loop). Resume the program so that it runs to the breakpoint.

Move your mouse over IOSET2 in the line just above the breakpoint. You should see a small window pop up showing you that IOSET0 is a macro defined to the value 0xE0028024. This value is a memory address, and writing 0xFFFFFFFF ("all ones") to that address activates some of the LEDs on the UNI-DS6. As you can see, LEDblink did this just before reaching the breakpoint.

To check the current value of IOSET2, click on the Console window at the bottom of the screen. Your mouse cursor should appear. Move the mouse cursor to the last line and type:

x 0xE0028024

The Console window should print out:

0xe0028024:    0xffffffff

eclipse debugmem.png

Run Other Text Commands

You can run other GDB text commands from the Console window. You can find a full list of GDB commands at http://web.cecs.pdx.edu/~jrb/cs201/lectures/handouts/gdbcomm.txt .

End your Debugging Session

To stop debugging, go to Run > Disconnect in the top menu. You can leave Debug perspective and return to the C/C++ perspective (the window layout you saw when you first loaded your project) with Window > Open Perspective > C/C++.

GDB Debugger with OpenOCD

From TinCanTools
(Redirected from GDB Debugger with OpenOCD)
Jump to: navigation, search

This guide was written for Ubuntu 10.04. For the windows page, see Windows GDB Debugger.

GDB, the GNU Project Debugger is a debugging tool provided with the GNU Compiler Collection (GCC). GDB allows you to stop and start a running program, examine its functioning, and make changes.

GDB Support in OpenOCD

The configure script provided with OpenOCD 0.5.0 already compiles OpenOCD to support the GDB debugger. The OpenOCD Ubuntu Package also includes GDB Support. If you have installed OpenOCD according to the guides on the Compiling OpenOCD page, your version of OpenOCD already supports GDB.

The -g flag tells the gcc compiler to build with GDB support. OpenOCD's configure script already includes the -g flag.

GDB Debugger is provided by default on Ubuntu 10.04. However, this version of GDB is only built to debug programs running on a Linux PC. You will need to download or compile a version of GDB that supports embedded devices. One such GDB build is provided with the CodeSourcery ARM toolchain.

Installing the CodeSourcery ARM Toolchain

CodeSourcery provides development tools for use with embedded devices, including a GCC cross-compiler and a GDB build for ARM targets. Download the latest version of the .bin installer from http://www.codesourcery.com/sgpp/lite/arm/portal/release1592. Direct link is here. Save this file anywhere on your computer, then navigate to it in a terminal window.

Run the installer like this:

sh arm-2010.09-51-arm-none-eabi.bin

You should see a loading bar followed by an installer GUI. However, you may see an error stating that the installer doesn't support the DASH shell.

Arm-none-eabi dash err.png

If you see this error, disable DASH by typing

sudo dpkg-reconfigure -plow dash

This will give you the option to enable DASH by choosing <YES> or disable it by choosing <NO>. Choose no and run the installer again.

 sh arm-2010.09-51-arm-none-eabi.bin

You should see the installer GUI now. The installer is fairly straightforward. This guide will assume that you choose the default option on each page.

Sourcery-install.png

The installer installs the CodeSourcery toolchain to your home directory. Add it to your PATH by editing your environment variables:

sudo cp /etc/environment /etc/backup_environment
sudo gedit /etc/environment

This backs up your environment file and then opens it a text editor. (The backup is just in case something goes wrong; unless you make a mistake, you can delete backup_environment later.) Find the line "Path=…" (probably the only line). Add the following to the end of that line, inside the quotes:

:~/CodeSourcery/Sourcery_G++_Lite/bin

That line should now read something like this:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:~/CodeSourcery/Sourcery_G++_Lite/bin"

Restart your computer.

Make sure everything installed correctly by running arm-none-eabi-gcc from anyhere, with no arguments. If everything installed correctly, you will see:

arm-none-eabi-gcc: no input files

Starting GDB

In the terminal window, run arm-none-eabi-gdb from any directory.

arm-none-eabi-gdb

Your terminal window should look like the image below, with a prompt reading (gdb) in place of the normal > command prompt.

Eabi-gdb startup.png

Connecting to OpenOCD

Run OpenOCD as normal, as described in Running OpenOCD on Linux. To connect to OpenOCD, start GDB as above:

arm-none-eabi-gdb

OpenOCD listens for GDB connections on port 3333. In GDB, connect to OpenOCD by typing target remote localhost:3333. (In this guide if you see (gdb) at the beginning of a command, that means enter that line into the GDB command prompt. Don't actually type the characters (gdb).)

(gdb) target remote localhost:3333

Before doing anything else, run reset init on the target. Use the monitor command to tell GDB to send the command to OpenOCD, like this:

(gdb) monitor reset init

Monitor reset init.png

This is important. You need to do this while GDB is connected to the OpenOCD, or you won't be able to halt or reset the target. If you don't run monitor reset init, you will encounter errors like this:

Gdb packet err.png

Sending Commands to OpenOCD

You can send commands to OpenOCD through GDB just like you can through a telnet connection. Type monitor, then the command, then enter. You can see a list of common OpenOCD commands here.

Gdb openocd commands.png

You can use the Linux command cd to change the current working directory in GDB. This changes the current directory only for GDB, not for Linux; when you exit GDB, you will be back in the directory where you started.

To quit GDB, type quit.

.gdbinit

Instead of typing commands yourself every time you start GDB, you can create a script to always start GDB with the same series of commands. This script file is named .gdbinit. GDB looks for it in the current working directory.

You can use the script below to have GDB automatically connect to OpenOCD and run reset init on the target. Create a new folder in your home directory called GDB_OpenOCD_init, and a new text file in that folder. Copy the code below into the file:

echo Executing GDB with .gdbinit to connect to OpenOCD.\n
echo .gdbinit is a hidden file. Press Ctrl-H in the current working directory to see it.\n
# Connect to OpenOCD
target remote localhost:3333
# Reset the target and call its init script
monitor reset init
# Halt the target. The init script should halt the target, but just in case
monitor halt

Save the file as .gdbinit and close it. Like any file whose name begins with a period, .gdbinit is a hidden file. To see it, open the folder and press CTRL-H.

To test the init script, start OpenOCD as normal. Then navigate to GDB_OpenOCD_init/ and run CodeSourcery GDB.

cd ~/GDB_OpenOCD_init
arm-none-eabi-gdb

You should see something like the image below. (In this image the target device is the Beagleboard. With different hardware the output of reset init will be different.)

Gdbinit.png

Debugging a Program on the Beagleboard

This part of the guide will demonstrate how to run and debug a simple program on the Beagleboard. The program will only work on the Beagleboard, but the commands are the same on other target devices.

Installing Packages

For this section you will need the Ubuntu packages git and make. Install the following packages by opening a new terminal window and typing:

sudo apt-get install git make

You may see a message stating that these pachages are already installed. That's fine.

Compiling LEDblink

Navigate to your home directory and use git to clone into https://github.com/mlu/cortal_dendrites.git.

cd ~
git clone https://github.com/mlu/cortal_dendrites.git

You should now have a folder in your home directory called cortal_dendrites/. Navigate to /home/USERNAME/cortal_dendrites/cortex_a8/standalone/LEDblink. This directory contains the source for LEDblink. Run make to compile it.

cd ~/cortal_dendrites/cortex_a8/standalone/LEDblink
make

The folder should now contain a binary file called LEDblink. It also contains a hidden file called .gdbinit. This script should start GDB and load LEDblink, but the file is outdated and no longer works. Delete it so that you can't accidentally run it later.

rm .gdbinit

Loading LEDblink

Start OpenOCD as normal, then open a new terminal window. Run GDB, connect it to OpenOCD, and reset the Beagleboard. You can do this manually:

arm-none-eabi-gdb
(gdb) target remote localhost:3333
(gdb) monitor reset init

…or using the .gdbinit script you created above:

cd ~/GDB_OpenOCD_init
arm-none-eabi-gdb

Beagle usrleds.png

The USR0 and USR1 LEDs on the Beagleboard should now be off. The Beagleboard has just been reset and is halted. Tell the Beagleboard to resume to let it boot. You should see USR0 and USR1 come on.

(gdb) monitor resume

Wait for the lights to come on, and then halt the Beagleboard again.

(gdb) monitor halt

Navigate to the directory containing LEDblink and load it:

(gdb) cd ~/cortal_dendrites/cortex_a8/standalone/LEDblink
(gdb) load LEDblink
(gdb) symbol-file LEDblink

Ledblink load.png

Now run the program by typing:

(gdb) cont

You should see the USR0 and USR1 LEDs pulse on and off in sequence. LEDblink will run forever if you let it. When you're ready to stop it, press CTRL-C in the GDB terminal. To start it again, type cont again.

Breakpoints

When debugging a program it's often useful to stop it in the middle to see what it's doing. You can do that with GDB using breakpoints. When you ran the command symbol-file LEDblink above, you loaded a file that allows GDB to map lines and functions in the source code to instructions in the executable. You can now instruct GDB to stop the program when it reaches a particular line or function.

Add a breakpoint associated with line 22 of LEDblink.c, then let LEDblink continue, like this:

(gdb) break 22
(gdb) cont

GDB will run until it hits line 22, then return you to the command prompt. Line 22 is inside a loop that never terminates, so GDB will hit this breakpoint over and over. Each time GDB hits the breakpoint, you can tell it to proceed by typing cont again.

You can have multiple breakpoints at a time. Type:

(gdb) break 30

…to create a second breakpoint at line 30. You can get a list of all breakpoints by typing:

(gdb) info breakpoints

info breakpoints lists your breakpoints by number. You can delete a breakpoint by entering delete followed by a number.

(gdb) delete 1

…deletes Breakpoint 1.

Ledblink breakpoints.png

Reading Memory

You can use GDB to read the value stored in a memory address with the x command. Type x followed by a memory address to output the value at that address. GDB assumes that the address is in decimal format unless you preface it with 0x to indicate hexadecimal. Memory addresses are usually expressed in hexadecimal, so remember to type 0x.

(gdb) x 0x49056090

Gdb x.png

The values at 0x49056090 and 0x49056094 control the USR0 and USR1 LEDs. The 22nd bit of each (0x00400000, in hex) controls USR0, and the 21st bit (0x00200000) controls USR1. Writing to 0x49056090 turns a light off, and writing to 0x49056094 turns a light on.

address 0x49056090 = 0x00400000: turn USR0 off

address 0x49056090 = 0x00200000: turn USR1 off

address 0x49056090 = 0x00600000: turn both LEDs off

address 0x49056094 = 0x00400000: turn USR0 on

address 0x49056094 = 0x00200000: turn USR1 on

address 0x49056094 = 0x00600000: turn both LEDs on

You can type x 0x49056090 and x 0x49056094 when LEDblink reaches a breakpoint to see what the program is doing.

External Links

GDB man page

GDB Debugger LPC2214

From TinCanTools
(Redirected from GDB Debugger LPC2214)
Jump to: navigation, search

GDB, the GNU Project Debugger is a debugging tool provided with the GNU Compiler Collection (GCC). GDB allows you to stop and start a running program, examine its functioning, and make changes.

The Eclipse IDE is a multi-language integrated development environment which can be used to develop, install, and debug embedded applications.

This guide will walk you through installing Eclipse and configuring it for embedded development, installing a GCC toolchain to compile programs for ARM processors, and finally compiling and debugging a simple program in GDB. These instructions were written for Ubuntu 12.04 LTS.

Install the ARM EABI Toolchain

To compile programs for ARM processors you will need a cross-compiler and toolchain. This guide will compile and install the ARM EABI toolchain via a script created by James Snyder.

Step 1: Download the Script via Git.

Git is version-control software used for managing code and assets during software development. Here we use it to download Snyder's script. In a terminal window, type:

sudo apt-get install git

When the install finishes, type:

cd ~
git clone https://github.com/jsnyder/arm-eabi-toolchain.git

download jsnyder script.png

This will create a folder called arm-eabi-toolchain in your Home directory, containing the makefile script we need.

Step 2: Install Dependencies.

The makefile requires several utilities and libraries to compile and install correctly. In a terminal window type (all on one line):

sudo apt-get install curl flex bison libgmp3-dev libmpfr-dev texinfo 
libelf-dev autoconf build-essential libncurses5-dev libmpc-dev

WARNING: Don't try to copy and paste the text above into your terminal window! If you want to copy and paste so you don't miss anything, use the line below:

sudo apt-get install curl flex bison libgmp3-dev libmpfr-dev texinfo libelf-dev autoconf build-essential libncurses5-dev libmpc-dev

Select the text in your browser, press Ctrl+C, then right-click on the terminal window and select Paste. Press Enter to install.

jsnyder deps.png

You can find this list of dependencies in Snyder's readme file, installed at /home/USERNAME/arm-eabi-toolchain/readme.md.

Step 3: Install libexpat.

Before we compile the toolchain we need to install one more library. In the terminal window, type:

sudo apt-get install libexpat-dev

Without this library, the toolchain will compile successfully but the debugger won't be configured to load software to the correct place in the board's memory. You may see an error stating that libexpat-dev has an unmet dependency: the wrong version of another library libexpat1. In that case, use this instead to install with the correct version of libexpat1:

sudo apt-get install libexpat1=2.0.1-7.2ubuntu1 libexpat-dev

Step 4: Execute the Makefile.

Navigate to /home/USERNAME/arm-eabi-toolchain and execute the makefile with sudo make install-cross:

cd ~/arm-eabi-toolchain
sudo make install-cross

jsnyder install.png

The script downloads the source code for the toolchain, compiles them, and installs.

Step 5: Wait.

The makefile will take a long time to run – possibly upwards of an hour. When it finishes, check back over the last several lines in the terminal window to make sure there were no errors. If everything went correctly, you should now have a folder in your Home directory called arm-cs-tools.

Step 6: Add the Cross-Compiler Tools to PATH.

In a terminal window, navigate to /etc and open the file called environment in a text editor. We'll use gedit, the text editor installed by default on Ubuntu.

cd /etc
sudo gedit environment

The first line of environment is a list of directories Ubuntu uses to search for executables. Add the following text to the beginning of the list, right after the open-quote:

$HOME/arm-cs-tools/bin:$HOME/arm-cs-tools/libexec/gcc/arm-none-eabi/4.7.3:

environment arm cs tools.png

Save the file and exit. Now back in the terminal window, update your PATH by typing:

source /etc/environment

The directories containing the cross-compiler executables should now be in your PATH. You can verify by typing:

echo $PATH

To make sure Ubuntu can find the cross-compiler, type:

arm-none-eabi-gcc --version

You should see a printout with version information.

path arm cs tools.png

Remember this Later…

You may get a "Command not found" error when trying to run part of the toolchain. When you restart your computer, your path may change. You can fix this by resetting PATH from the file you edited earlier:

source /etc/environment

Also, the sudo command changes your PATH. It won't matter for the rest of this guide, but if you ever need to access part of the toolchain with sudo you can do so like this:

sudo env PATH=$PATH command_here

Install and Configure Eclipse

Step 1: Install Java.

Eclipse can be used to develop programs for multiple languages, but the Eclipse software itself runs in Java. If you're not sure whether you have Java installed already, open a terminal window and type:

java --version

If you have a Java Runtime Environment (JRE) installed, you will see the name of the distribution and a version number. Note for users unfamiliar with Java development: The Java Runtime Environment (JRE) and the Java plugin that runs applets in your web browser are two different things. What we need is the JRE.

To install the JRE, type in a terminal window:

sudo apt-get install openjdk-7-jre

Press 'Enter' on your keyboard, then 'y' when prompted.

install openjdk.png

Once installation completes you can verify that everything installed correctly by typing java –version again.

java --version

Step 2: Download Eclipse.

Go to http://www.eclipse.org/downloads in your browser. Download the Eclipse IDE for C/C++ Developers. There are different versions for 32- and 64-bit Linux; download the one appropriate to your computer's operating system.

Open the archive and extract it to your Home folder.

Doubleclick the eclipse executable to start the IDE. You should see this loading screen:

eclipse loadscreen.png

Next Eclipse will prompt you to select a workspace:

eclipse workspace.png

This will create a new directory to store your Eclipse projects. This guide will assume you use the default /home/USERNAME/workspace. Click OK.

Step 3: Install the Eclipse CDT Plugin.

You should now be at the Eclipse welcome screen.

eclipse welcome.png

At the top of the window, go to Help > Install New Software… to bring up the Install window. In the text bar at the top of the window, enter the following URL:

http://download.eclipse.org/tools/cdt/releases/kepler

eclipse installcdt.png

You should see two options: CDT Main Features and CDT Optional Features. Click the checkboxes next to each and click Next to go to a list of features to be installed:

eclipse installcdt2.png

Click Next again to install.

Step 4: Install Cross Development Tools.

In the Eclipse window, go again to Help > Install New Software… This time in the text bar at the top of the window, enter:

http://gnuarmeclipse.sourceforge.net/updates

eclipse installcross.png

Check the box net to CDT GNU Cross Development Tools, hit Next, and then Next again to install.

Create a Simple Eclipse Project

Step 1: Download LPC2214_LEDblink.

LPC2214_LEDblink is a simple program that will repeatedly blink the red LED banks on the UNI-DS6. Download it here:

Download LPC2214_LEDblink

Open the archive and extract the contents to your Home folder.

Step 2: Create a New Eclipse Project.

In Eclipse, look at the menu at the top of the screen. Select New > Makefile Project with Existing Code. The New Project window should appear. Configure your new project as follows:

  • Give the project a name.
  • In Existing Code Location, browse to /home/USERNAME/LPC2214_LEDblink and click OK.
  • Check C under Languages.
  • Under Toolchain for Indexer Settings, select Cross GCC.

eclipse newproject.png

Click Finish to create your project. You can now view your project heirarchy in the Eclipse Project Explorer window (on the left in the picture below).

eclipse justmadeproject.png

Step 3: Set your Project's PATH Variable.

Earlier, we set the PATH variable so your operating system could find the ARM EABI toolchain executables. When Eclipse creates a new project it imports your PATH and uses it by default. Just one problem: Eclipse can't parse the $HOME variable in your PATH, so you'll have to edit your project settings.

In the Project Explorer window, left-click on the top level of your project to select it. Then in the menu at the top, go to Project > Properties. Expand C/C++ Build and select Environment.

eclipse setpath.png

Select PATH and click Edit to bring up the Edit Variable window. Add the following text to the beginning of the text box:

/home/USERNAME/arm-cs-tools/bin:/home/USERNAME/arm-cs-tools/libexec/gcc/arm-none-eabi/4.7.3:

…but replace USERNAME with your Linux username. Don't use $HOME or the tilde (~) symbol in place of /home/USERNAME.

eclipse setpath2.png

Click OK. Then back in the Properties window, click Apply then OK.

Step 4: Set your Project's Debug Configuration.

Back on the Eclipse main screen, click on the top level of your project again to select it. Then in the top menu go to Run > Debug Configurations. A new window should appear. In the menu on the left, expand GDB Hardware Debugging and select ledblink Default (or whatever you named your project).

eclipse setdebugger.png

To the right, select the Debugger tab.

  • Change GDB Command to arm-none-eabi-gdb. (It should say gdb by default.)
  • Change Port number to 3333.

eclipse setdebugger2.png

Now go to the Startup tab.

  • Uncheck Reset and Delay.
  • Uncheck Halt.
  • In the textbox beneath Reset and Delay and Halt, type the following:
monitor halt
monitor reset init
  • Make sure the settings under Load Image and Symbols look like the image below. (You shouldn't need to change anything.)

eclipse setdebugger3.png

Click the Apply button, then click Close.

Step 5: Build your Project.

In the top menu, go to Project > Build All. If the project compiles successfully you should see new object files appear in the Project Explorer.

eclipse built.png

Load and Debug the Program with GDB

For this step, you will need a Flyswatter2, OpenOCD and a configuration file for the lpc2214 chip. If you haven't already installed OpenOCD and downloaded lpc2214.cfg, go to Flyswatter2 LPC2214 How To and follow the instructions there.

Step 1: Start OpenOCD.

Connect your Flyswatter2 and mikroBoard / UNI-DS6. Open a terminal window and run OpenOCD as described in the Flyswatter2 LPC2214 How To.

cd ~/openocd-bin
sudo ./openocd -f interface/flyswatter2.cfg -f target/lpc2214.cfg -c init -c "reset init"

ocdstartup lpc2214.png

Step 2: Start GDB and Load the Program.

Back in Eclipse, select the top level of your project. In the top menu go to Run > Debug Configurations. Expand the GDB Hardware Debugging Tab and select ledblink Default. You should now be back where you were when you set your debug settings earlier.

Note: The C/C++ Application text area may be blank. If it is, click the Search Project… button and select main.out.

eclipse setdebugger.png

This time, click Debug. You will be prompted to switch to a Debug perspective. Click Yes.

eclipse switchperspective.png

This will change Eclipse's layout to show debugging information. (Later you can get back to the old perspective from the top menu: Window > Open Perspective > C/C++.) The Debug perspective looks something like this:

eclipse debugperspective.png

Go back to your OpenOCD terminal window and make sure it reset properly. You should see something like this:

eclipse gbd openocd connect.png

Step 3: Resume the Program.

The LEDblink program should now be in your board's flash memory. However, nothing should be happening yet. In the Eclipse top menu, go to Run > Resume. You should see the red LED banks on the UNI-DS6 blink on and off.

This may not work on the first try because of hardware issues with the UNI-DS6. If the LEDs don't blink but you don't see any errors in Eclipse, try reloading the program:

  • Terminate the program. (Top menu in Eclipse: Run > Terminate.)
  • Don't restart OpenOCD or rest the UNI-DS6.
  • Build and load the program again, as in Step 2 above.

If that fails, try restarting the UNI-DS6:

  • End your debugging session. (Top menu in Eclipse: Run > Disconnect.)
  • Shut down OpenOCD.
  • Turn the power switch on the UNI-DS6 off and then on again. LEDblink is still in flash memory, so the LED blanks should start blinking immediately on startup.
  • Try again from Step 1: Start OpenOCD.

Be sure to try both solutions. The first may work when the second fails, or vice versa.

Using GDB in Eclipse

Eclipse provides a GUI wrapper around the most common GDB commands. Normally you would run GDB commands from a terminal window, but you can perform several GDB actions through Eclipse.

Suspend and Resume the Program

To pause the program, use the top menu, Run > Suspend. Try this and you should see the LEDs on the UNI-DS6 stop flashing. To resume, use Run > Resume or press F8 on your keyboard.

Insert a Breakpoint

A breakpoint suspends the program each time it reaches a particular line of code. Breakpoints allow you to read the contents of memory before the program can change it, or find errors by verifying that the program runs correctly up to a particular point.

First suspend the program as above (Run > Suspend). In the code view for main.c at the center left of the Eclipse screen, click to place your mouse cursor in line 79. Line 79 should read:

delay_ms(150);

In the top menu, select Run > Toggle Breakpoint. Alternatively you can press Shift+Ctrl+B on your keyboard. A blue dot should appear to the left of Line 79.

eclipse breakpoint.png

Resume the program (Run > Resume or F8). The program will run until it reaches the breakpoint and then suspend automatically. You should see the LEDs on the UNI-DS6 flash off once, then come back on and stay on. Because this breakpoint is in the middle of a loop that never terminates, you can keep repeating this indefinitely. Each time you resume the program, the lights should flash off once and then come back on.

To remove the breakpoint, select Run > Toggle Breakpoint or press F8 again. Do that now.

Check the Value of a Variable

While the program is suspended, Eclipse shows you the current value of variables. Insert a new breakpoint at Line 57. Just as before, suspend the program (Run > Suspend), place your cursor in Line 57 and select Run > Toggle Breakpoint or press F8. Line 57 is a for loop that forces LEDblink to delay between flashes:

for (j = 0; j < 4000; j++ );

Insert a new breakpoint at Line 57. Resume the program with Run > Resume or F8. This breakpoint is at a head of a nested loop within another for loop:

for (i = 0; i < ms; i++ )
for (j = 0; j < 4000; j++ );

So each time the the breakpoint is reached, the value of i should increase by 1. Look at the value of i in the Variables window at the upper right.

eclipse debugvar.png

Resume the program again, and the value of i should increase by 1.

Check the Value of a Memory Address

Unfortunately we can't use the Eclipse GUI to read the values that turn the LEDs on and off. However, we can get those values from memory directly using GDB text commands. Remove the breakpoint at Line 57 and put a new one back at Line 79 where we had it earlier (delay_ms(150); in the middle of the while loop). Resume the program so that it runs to the breakpoint.

Move your mouse over IOSET2 in the line just above the breakpoint. You should see a small window pop up showing you that IOSET0 is a macro defined to the value 0xE0028024. This value is a memory address, and writing 0xFFFFFFFF ("all ones") to that address activates some of the LEDs on the UNI-DS6. As you can see, LEDblink did this just before reaching the breakpoint.

To check the current value of IOSET2, click on the Console window at the bottom of the screen. Your mouse cursor should appear. Move the mouse cursor to the last line and type:

x 0xE0028024

The Console window should print out:

0xe0028024:    0xffffffff

eclipse debugmem.png

Run Other Text Commands

You can run other GDB text commands from the Console window. You can find a full list of GDB commands at http://web.cecs.pdx.edu/~jrb/cs201/lectures/handouts/gdbcomm.txt .

End your Debugging Session

To stop debugging, go to Run > Disconnect in the top menu. You can leave Debug perspective and return to the C/C++ perspective (the window layout you saw when you first loaded your project) with Window > Open Perspective > C/C++.

Flyswatter3 RouterStationPro Windows How To

From TinCanTools
Jump to: navigation, search

This guide will walk you through connecting the Flyswatter3 and the Ubiquiti RouterStation Pro to your Windows PC, and installing and running OpenOCD. This guide was tested with Windows XP and Windows 7. Instructions are identical on 32-bit and 64-bit versions of Windows unless otherwise noted.

Connecting the Flyswatter3 and the RouterStation Pro

To hook up the Flyswatter3 and the RouterStation Pro, you will need:

  • Flyswatter3
    • USB Male A/Male B Cable
    • 14-pin JTAG Ribbon Cable
  • RouterStationPro
    • RS-232 Serial Cable with two female connectors
    • CAT6 Cable
    • Power Over Ethernet Injector (with power cable)

The items listed under Flyswatter3 ship with the Flyswatter3. The items listed under RouterStationPro are included with the MIPS Linux Starter Kit.

Connect the JTAG ribbon cable to the Flyswatter3.

Fs3 jtagcable.png

The ribbon cable should have a notch on the connector to force it into the correct position. If it doesn't, make sure to align Pin 1 of the adapter as shown in the image to the left. (Pin 1 is on the side of the cable with the red stripe.)


Connect the Other End of the Ribbon Cable to the RouterStation Pro.

Fs3 rspro jtag.png

Again, be sure to align the red stripe with Pin 1, as shown in the picture. Pin 1 is toward the outer edge of the board. It is also marked on the bottom of the RouterStation Pro.


Connect the RS-232 Serial Cable.

Fs3 rspro bothcables.png

Connect the cable as shown in the picture.


Connect the USB Cable to the Flyswatter3.

Fs3 rspro usb.png

Connect the Male B adapter to the Flyswatter3. (The Male B end is the squarish end, not the flat end.)


Connect the CAT6 Cable to the Power Over Ethernet Injector.

Poe cat6.png

Leave the boards alone for now. Find the Power Over Ethernet Injector in the MIPS Linux Starter Kit, and connect the CAT6 cable. The PoE injector has two ethernet ports, but only one supplies power. Be sure to use the correct one. The correct ethernet port is labeled.


Connect the Power Adapter to the Power Over Ethernet Injector.

Poe power.png

Connect the power cable to the other side of the PoE injector.


Connect the Other End of the CAT6 Cable to the RouterStation Pro.

Rspro poe.png

Connect the CAT6 cable to the RouterStation Pro's Power Over Ethernet port. Warning: The RouterStation Pro has three ethernet ports in addition to the PoE port. Connecting the PoE injector to one of the regular ethernet ports may damage the board. The PoE port is the closest to the center of the board, to the right of the three ethernet ports as shown in the picture. It is labeled POE on the board.


Plug the Power Adapter into a Wall Outlet.

The green LEDs on the RouterStation Pro should briefly flash, and the leftmost LED should remain on.

Plug the USB Cable into your PC.

The green power LED on the Flyswatter3 should come on and remain on.

Installing OpenOCD

OpenOCD (Open On-Chip Debugger) is open-source software that interfaces with the Flyswatter3. OpenOCD provides debugging and in-system programming for embedded target devices. You will need to compile OpenOCD from source, and patch the source with one of the OpenOCD Patches for Flyswatter 3 support.

Whichever guide you use, be sure to install the patch! All four guides include instructions on downloading and installing the patch.

Windows 7

Use Windows 7 guides if compiling for Windows Vista.

Compiling OpenOCD Win7

Compiling OpenOCD Win7 D2XX

Windows XP

Compiling OpenOCD WinXP

Compiling OpenOCD WinXP D2XX

The first set of instructions uses libFTDI, an open-source driver library for FTDI devices. The second set uses FTD2XX, a closed-source driver library from Future Technology Devices International.

Running OpenOCD

Now you are ready to run OpenOCD. Open a command line window; if you're not sure how to do this, see Running OpenOCD on Windows. Navigate to the folder containing openocd.exe (the openocd-bin folder you created in the compile guide) and type:

cd C:\openocd-bin
openocd -f interface/flyswatter3.cfg -c "jtag_khz 15000" -f target/ar71xx.cfg

When you start OpenOCD you should see something like this:

rspro ocdstartup win.png

Telnet Connection

You cannot enter commands directly to OpenOCD. Open a new command window and type:

telnet localhost 4444

You will should see this prompt:

Telnet win.png

You can give commands to OpenOCD through this prompt. If you don't see the prompt on Windows 7, you may need to enable the Telnet client. See Configuring Windows 7 for OpenOCD.

Common OpenOCD Commands

To see a full list of OpenOCD commands, enter help in the telnet window.

reset

Resets the RouterStation Pro. The output of the Reset command should look like this:

Rspro reset win.png

halt

Sends a halt request to the RouterStation Pro. If the RouterStation Pro halts, you will see text output in the telnet window. (If the RouterStation Pro is already halted, you will see no output.)

Rspro halt win.png

halt [timeout]

You can also use halt followed by a time in milliseconds. OpenOCD waits for the target to halt the specified amount of time, then gives up if the target has not halted. You can use this to avoid OpenOCD hanging because the RouterStation Pro fails to halt. For example, to send a halt command with a timeout of one second, type:

halt 1000

resume

Enter resume to end a halt. You will not see any text output in the telnet window.

reg

Displays a numbered list of all of the RouterStation Pro's registers.

Rspro reg win.png

If the board is not halted, the board registers will be displayed but not their values.

reg [entry]

Run reg with a register number to display the contents of a register, in hexadecimal. The register number corresponds to the output of the reg command with no arguments, above. You must run the halt command before reading registers.

Rspro reg0 win.png

If you run reg while the RouterStation Pro is not halted, you will still see the value stored in the register. However, registers change contents very quickly while the device is running; by the time you see the value, the value actually in the register may be different. If you try to run reg while the device is not halted, you will see this:

Rspro reg0nothalted win.png

Note that the RouterStation Pro does not show any warning if you run the reg command while the board is running.

reg [entry] [value]

Sets the value of a register. The register number corresponds to the output of the reg command with no arguments, above. Make sure the RouterStation Pro is halted (with the halt command) before you change the value of a register!

You can enter registry values in either decimal, by typing a number by itself, or in hexadecimal, by prefacing the value with 0x.

Rspro regset win.png

GDB Debugger

GDB, the GNU Project Debugger is a debugging tool provided with the GNU Compiler Collection (GCC). GDB allows you to stop and start a running program, examine its functioning, and make changes. To install and use GDB with OpenOCD, follow the instructions on the Windows GDB Debugger page below.

Windows GDB Debugger

The GDB debugger page will walk you through installing GDB for use with OpenOCD, and loading and testing a simple program.

Flyswatter3 RouterStationPro How To

From TinCanTools
Jump to: navigation, search

This guide will walk you through connecting the Flyswatter3 and the Ubiquiti RouterStation Pro to your Linux PC, and installing and running OpenOCD. This guide was written with Ubuntu 10.04.

Connecting the Flyswatter3 and the RouterStation Pro

To hook up the Flyswatter3 and the RouterStation Pro, you will need:

  • Flyswatter3
    • USB Male A/Male B Cable
    • 14-pin JTAG Ribbon Cable
  • RouterStationPro
    • RS-232 Serial Cable with two female connectors
    • CAT6 Cable
    • Power Over Ethernet Injector (with power cable)

The items listed under Flyswatter3 ship with the Flyswatter3. The items listed under RouterStationPro are included with the MIPS Linux Starter Kit.

Connect the JTAG ribbon cable to the Flyswatter3.

Fs3 jtagcable.png

The ribbon cable should have a notch on the connector to force it into the correct position. If it doesn't, make sure to align Pin 1 of the adapter as shown in the image to the left. (Pin 1 is on the side of the cable with the red stripe.)


Connect the Other End of the Ribbon Cable to the RouterStation Pro.

Fs3 rspro jtag.png

Again, be sure to align the red stripe with Pin 1, as shown in the picture. Pin 1 is toward the outer edge of the board. It is also marked on the bottom of the RouterStation Pro.


Connect the RS-232 Serial Cable.

Fs3 rspro bothcables.png

Connect the cable as shown in the picture.


Connect the USB Cable to the Flyswatter3.

Fs3 rspro usb.png

Connect the Male B adapter to the Flyswatter3. (The Male B end is the squarish end, not the flat end.)


Connect the CAT6 Cable to the Power Over Ethernet Injector.

Poe cat6.png

Leave the boards alone for now. Find the Power Over Ethernet Injector in the MIPS Linux Starter Kit, and connect the CAT6 cable. The PoE injector has two ethernet ports, but only one supplies power. Be sure to use the correct one. The correct ethernet port is labeled.


Connect the Power Adapter to the Power Over Ethernet Injector.

Poe power.png

Connect the power cable to the other side of the PoE injector.


Connect the Other End of the CAT6 Cable to the RouterStation Pro.

Rspro poe.png

Connect the CAT6 cable to the RouterStation Pro's Power Over Ethernet port. Warning: The RouterStation Pro has three ethernet ports in addition to the PoE port. Connecting the PoE injector to one of the regular ethernet ports may damage the board. The PoE port is the closest to the center of the board, to the right of the three ethernet ports as shown in the picture. It is labeled POE on the board.


Plug the Power Adapter into a Wall Outlet.

The green LEDs on the RouterStation Pro should briefly flash, and the leftmost LED should remain on.

Plug the USB Cable into your PC.

The green power LED on the Flyswatter3 should come on and remain on.

Installing OpenOCD

OpenOCD (Open On-Chip Debugger) is open-source software that interfaces with the Flyswatter3. OpenOCD provides debugging and in-system programming for embedded target devices. You will need to compile OpenOCD from source, and patch the source with one of the OpenOCD Patches for Flyswatter 3 support.

Whichever guide you use, be sure to install the patch! Both guides include instructions on downloading and installing the patch.

Compiling OpenOCD Linux

Compiling OpenOCD Linux D2XX

The first set of instructions uses libFTDI, an open-source driver library for FTDI devices. The second set uses FTD2XX, a closed-source driver library from Future Technology Devices International.

Running OpenOCD

Now you are ready to run OpenOCD. If you installed the OpenOCD Ubuntu package, open a terminal window and type the following from any directory:

openocd -f interface/flyswatter3.cfg -c "jtag_khz 15000" -f target/ar71xx.cfg

If you compiled OpenOCD yourself, navigate to the openocd-bin directory you created in the compile guide and type:

cd ~/openocd-bin
sudo ./openocd -f interface/flyswatter3.cfg -c "jtag_khz 15000" -f target/ar71xx.cfg

Your terminal window should now look something like this:

Fs3 rspro ocdstartup.png

Telnet Connection

You cannot enter commands directly to OpenOCD. Open a new terminal window and type:

telnet localhost 4444

You will should see this prompt:

Telnet.png

You can give commands to OpenOCD through this prompt.

Common OpenOCD Commands

To see a full list of OpenOCD commands, enter help in the telnet window.

reset

Resets the RouterStation Pro. The output of the Reset command should look like this:

Rspro reset.png

halt

Sends a halt request to the RouterStation Pro. If the RouterStation Pro halts, you will see text output in the telnet window. (If the RouterStation Pro is already halted, you will see no output.)

Rspro halt.png

halt [timeout]

You can also use halt followed by a time in milliseconds. OpenOCD waits for the target to halt the specified amount of time, then gives up if the target has not halted. You can use this to avoid OpenOCD hanging because the RouterStation Pro fails to halt. For example, to send a halt command with a timeout of one second, type:

halt 1000

resume

Enter resume to end a halt. You will not see any text output in the telnet window.

reg

Displays a numbered list of all of the RouterStation Pro's registers.

Rspro reg.png

If the board is not halted, the list of registers will be displayed but not their values.

reg [entry]

Run reg with a register number to display the contents of a register, in hexadecimal. The register number corresponds to the output of the reg command with no arguments, above. You must run the halt command before reading registers.

Rspro reg0.png

If you run reg while the RouterStation Pro is not halted, you will still see the value stored in the register. However, registers change contents very quickly while the device is running; by the time you see the value, the value actually in the register may be different. If you try to run reg while the device is not halted, you will see this:

Rspro reg0 nothalted.png

Note that the RouterStation Pro does not show any warning if you run the reg command while the board is running.

reg [entry] [value]

Sets the value of a register. The register number corresponds to the output of the reg command with no arguments, above. Make sure the RouterStation Pro is halted (with the halt command) before you change the value of a register!

You can enter registry values in either decimal, by typing a number by itself, or in hexadecimal, by prefacing the value with 0x.

Rspro regset.png

GDB Debugger

GDB, the GNU Project Debugger is a debugging tool provided with the GNU Compiler Collection (GCC). GDB allows you to stop and start a running program, examine its functioning, and make changes. GDB is installed on Ubuntu 10.04 by default, but you will need a different version of GDB build for embedded targets. Follow the instructions on the GDB Debugger page below.

GDB Debugger

The GDB debugger page will walk you through installing GDB for use with OpenOCD, and loading and testing a simple program.