Файл: ARM cross development with Eclipse, version 2 (J.P. Lynch, 2005).pdf

It’s also convenient to click on the “Debug Perspective” button on the upper right of the Eclipse screen.

You can drag this s- shaped edge to expose all the available perspectives.

Below is the “Debug” perspective.

When everything works, the GDB Debugger communicates using the GDB Serial Protocol to an internet socket called localhost:8888, we specified this in our Embedded Debug Launch Configuration (the “command” tab).

The Macraigor OCDRemote DLL intercepts the GDB Serial Protocol via the internet socket and converts it into JTAG signals on the LPT1 printer port connector. The Wiggler device merely translates the JTAG signals to 3.3 volts for use with the Philips LPC2106 microprocessor.

Here is an example of OCDRemote failing.

Note that it says “terminated”

Oooops, got an error message in the console!

If you have trouble getting OCDremote to start; try these remedies:

•You may have accidentally started multiple copies of OCDremote. Bring up the Windows Task Manager (ctrl-alt-del) and search the list of running tasks. If there are multiples of ocdremote.exe, terminate all of them and start over.

•Keep trying; I’ve clicked it ten times before it started (this is simply Voodoo).

•Go to bed; let it win tonight.

E.Start the Debugger

Our “Debug Configuration” has been defined and we’ve switched to the Debug perspective. We started the OCDRemote utility and verified that it’s working.

Now is the time to start the debugger. Since the “Embedded Debug Launch” configuration “demo2106_blink_ram” was the last configuration accessed above, clicking on the “Bug” button will suffice. If you’re not sure, use the pull-down” arrow to see exactly what configuration will be started.

Either one

will start the

Debugger.

The Debugger will start up and execute the two commands specified earlier. It will connect to the target via JTAG and start a download of the application. You can watch the progress bars at the lower right of the screen.

Watch the download progress bars here.

When downloading completes, the Debugger is in “idle” mode with the executable code loaded into RAM.

You can see above in the “console” view that the debugger executed our two commands specified in the launch configuration earlier. It followed that with the download of the .text and .data sections.

The downloading is very slow. We specified the next to slowest speed 7. Attempting a faster speed with the Olimex wiggler will probably prove futile.

The debugger is “idle”, waiting for you to issue a command.

F.Run to Main

The first move is to start the application. It will stop at the main() program; we specified this earlier in our launch configuration setup.

In the Debug view, click on the green arrow to start execution of the application..

The application will start, run all of our ARM initialization code and stop at the start of main(). Note that in the Debug view, the Thread[0] is suspended at line 46 of main. With embedded cross development, we only have one execution thread. Code targeted for the PC platform can have multiple threads of execution.

Run to Main() stopped here

G.Components of the DEBUG Perspective

Before operating the Eclipse debugger, let’s review the components of the Debug perspective.

Assembler

Display

C Code Display

GDB Debugger

Command Window

H.Debug Control

The Debug view should be on display at all times. It has the Run, Stop and Step buttons. The tree-structured display shows what is running; in this case it’s the OCDRemote utility and our application, shown as Thread[0].

Tree-view shows what’s running.

Notes: When you resume execution by clicking on the Run/Continue button, many of the buttons are “grayed out.” Click on “Thread[0]” to highlight it and the buttons will re-appear. This is due to the possibility of multiple threads running simultaneously and you must choose which thread to pause or step. In our ARM development system, we only have one thread.

All of these views, such as the Debug Control view above, can be maximized to full-screen, minimized or returned to multi-pane by the “maximize” and “minimize” buttons at the upper right corner.

I.Run and Stop with the Right-Click Menu

The easiest method of running is to employ the right-click menu. In the example below, the blue arrowhead cursor indicates where the program is currently stopped.

To go to the IOCLR = 0x00000080; statement several lines away, click on the line where you want to go (this should highlight the line and place the cursor there).

Now right click on that line. Notice that the rather large pop-up menu has a “Run to Line” option.

We were stopped here.

Right-click next to bring up this pop-up menu

When you click on the “Run to line” choice, the program will execute to the line the cursor resides on and then stop (N.B. it will not execute the line).

Now click on the “Run/Continue” button in the Debug view.

Assuming that this is the only breakpoint set, the program will execute to the breakpoint line and stop.

Stops before executing this

line.

Since this is a RAM application and breakpoints are “software” breakpoints, there can be a nearly unlimited number of breakpoints set.

The breakpoints can be more complex. For example, to ignore the breakpoint 5 times and then stop, right-click on the breakpoint symbol on the far left.

This brings up the pop-up menu below and click on “Breakpoint Properties …”.

Now when you hit the Run/Continue button again, the program will blink 5 times and stop. Don’t expect this feature to run in real-time. Each time the breakpoint is encountered the debugger will automatically continue until the “ignore” count is reached. This involves quite a bit of debugger communication at a very slow baud rate.

In addition to specifying a “ignore” count, the breakpoint can be made conditional on an expression. The general idea is that you set a breakpoint and then specify a conditional expression that must be met before the debugger will stop on the specified source line.

In this example, a line has been added to the blink loop that increments a variable “x”. Double-click on that line to set a breakpoint.

Right click on the breakpoint symbol and select “Breakpoint Properties”. In the

Breakpoint Properties window, set the condition text box to “x == 9”.

A nice feature of Eclipse debugging is that you can edit the source file within the debugger and rebuild the application without leaving the debugger. Of course, you need to kill the OCDRemote and the Debugger and restart the download after the build; as specified above. This is necessary for this release of CDT because the “Restart” button appears inoperative. The advantage is that you don’t have to change the Eclipse perspective – just stay in the Debug perspective.

Start the application and it will stop on the breakpoint line (this will take a long time, 9 seconds on my Dell computer). If you park the cursor over the variable x after the program has suspended on the breakpoint, it will display that the current value is 9.

Debugger stopped on this line only when x == 9

If you specify that it should break when x == 50000, you will essentially wait forever. The way this works, the debugger breaks on the selected source line every pass through that source line and then queries via JTAG for the current value of the variable x. When x==50000, the debugger will stop. Obviously, that requires a lot of serial communication at a very slow baud rate. Sadly, the OCDRemote and wiggler combination cannot service a hardware breakpoint (the ARM supports two hardware breakpoints that can stop on an address and/or data value). Still, you may find some use for this feature.

In the Breakpoint Summary view, shown directly below, you can see all the breakpoints you have created and the right-click menu lets you change the properties, remove or disable any of the breakpoints, etc. The example below shows one conditional breakpoint that will stop on source line 64 only if the variable x is equal to 9.