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

K.Single Stepping

Single-stepping is the single most useful feature in any debugging environment. The debug view has three buttons to support this.

Step Into

If the cursor is at a function call, this will step into the function.

It will stop at the first instruction inside the function.

If cursor is on any other line, this will execute one instruction.

Step Over

If the cursor is at a function call, this will step over the function. It will execute the entire function and stop on the next instruction after the function call.

If cursor is on any other line, this will execute one instruction

Step Out Of

If the cursor is within a function, this will execute the remaining instructions in the function and stop on the next instruction after the function call.

This button will be “grayed-out” if cursor is not within a function.

As a simple example, restart the debugger and set a breakpoint on a line in the Initialize() function. Hit the Start button to go to that breakpoint.

Set a breakpoint here.

Notice that the “Step Out Of” button is illuminated. Click the “Step Out Of” button

The debugger will execute the remaining instructions in feed() and return to just after the function call.

L.Inspecting and Modifying Variables

Before proceeding on this topic, let’s add a couple of structured variables to the simple blinker test program. After rebuilding the application and re-launching the debugger, we can inspect variables once a breakpoint has been encountered.

The simple way to inspect variables is to just park the cursor over the variable name in the source window; the current value will pop up in a tiny text box. Execution must be stopped for this to work; either by breakpoint or pause.

Text cursor is parked over the variable “z”

For a structured variable, parking the cursor over the variable name will show the values of all the internal component parts.

Text cursor is parked over the variable “Access”

Another way to look at the local variables is to inspect the “Variables” view. This will automatically display all automatic variables in the current stack frame. It can also display any global variables that you choose. For simple scalar variables, the value is printed next to the variable name.

If you click on a variable, its value appears in the summary area at the bottom. This is handy for a structured variable or a pointer; wherein the debugger will expand the variable in the summary area.

Click on this

The summary area will show what the pointer is

referencing.

The Variables view can also expand structures. Just click on any “+” signs you see to expand the structure and view its contents.

You can click on “+” signs to expand a structure variable and view its contents.

Global variables have to be individually selected for display within the “Variables” view.

Check the variables you want to display and then click “OK” add them to the Variables view,

Note: not sure what the extra variables are. Might be a CDT bug?

You can easily change the value of a variable at any time. Assuming that the debugger has stopped, click on the variable you wish to change and right click. In the right-click menu, select “Change Value…” and enter the new value into the pop-up window as shown below. In this example, we change the variable “c” to 52.

Now the “Variables” view should show the new value for the variable “c”. Note that it has been colored red to indicate that it has been changed.

M.Watch Expressions

The “Expressions” view can display the results of expressions (any legal C Language expression). Since it can pick any local or global variable, it forms the basis of a customizable variable display; showing only the information you want.

For example, to display the 6th character of the name in the structured variable “Access”, bring up the right-click menu and select “Add Watch Expression…”.

Enter the fully qualified name of the 6th character of the name[] array.

Note that it now appears in the “Expressions” view.

You can type in very complicated expressions. Here we defined the expression (i + z)/h

N.Assembly Language Debugging

The Debug perspective includes an Assembly Language view.

If you click on the Instruction Stepping Mode toggle button in the Debug view,

the assembly language window becomes active and the single-step buttons apply to the assembler window. The single-step buttons will advance the program by a single assembler instruction. Note that the “Disassembly” tab lights up when the assembler view has control.

Note that the debugger is currently stopped at the assembler line at address 0x400003f0.

The “Step Into” and “Step Out Of” buttons work in the same was as for C code.

O.Inspecting Registers

Unfortunately, parking the cursor over a register name (R3 e.g.) does not pop up its current value. For that, you can refer to the “Registers” view.

Click on the “+” symbol next to Main and the registers will appear. The Philips LPC2106 doesn’t have any floating point registers so registers F0 through FPS are not applicable.

If you don’t like a particular register’s numeric format, you can click to highlight it and then bring up the right-click menu.

The “Format” option permits you to change the numeric format to hexadecimal, for example.

Now the register display shows r4 in hexadecimal format.

Of course, the right click menu lets you change the value of any register. For example, to change r7 from zero to 0x1F8, just select the register, right-click and select “Change Value…”

Now the value for r7 has been changed to 0x1F8.

It goes without saying that you had better use this feature with great care! Make sure you know what you are doing before tampering with the ARM registers.

P.Inspecting Memory

Viewing memory is a bit complex in Eclipse. First, the memory view is not part of the default debug launch configuration. You can add it by clicking “Window – Show View – Memory” as shown below.

The memory view appears in the “Console” view at the bottom of the Debug perspective. At this point, nothing has been defined. Memory is displayed as one or

more “memory monitors”. To create a memory monitor, click on the “+” symbol.

Enter the address 0x400004f4 (address of the string “The Rain in Spain”) in the dialog box.

The memory monitor is created, although it defaults to 4-byte display mode. The display of the address columns and the associated memory contents is called a “Rendering”.

The address 0x400004F4 is called the Base Address; there’s a right-click menu option “Reset to Base Address” that will automatically return you to this address if you scroll the memory display.

There’s also a “Go to Address…” right-click menu option that will jump all over memory for you.

By right-clicking anywhere within the memory rendering (display area), you can select “Column Size – 1 unit”.

This will repaint the memory rendering in Byte format.

Now we will add a second rendering that will display the memory monitor in ASCII. Click on the “Toggle Split Pane” button to create a second rendering pane.

Pick “ASCII” display for the new rendering.

Click on the “Add Rendering(s)” button to create an additional ASCII memory display.

This means that scrolling one memory rendering will automatically scroll the other one in synchronism.

This will expand the display erasing the “memory monitors” list on the left.

Personally, I think this Eclipse memory display is a bit complex. However, it allows you to define many “memory monitors” and clicking on any one of them pops up the renderings instantly. It’s like so many things in life, once you learn how to do it; it seems easy!

23 The Author Sounds Off

This tutorial was designed for students and hobbyists; those with limited funds. It described in great detail how to download and install all the component parts of a complete ARM software development system and gave two simple code examples to try out. Of course, the beauty of this is that it’s completely free.

If you are a professional engineer attempting to build an ARM development system with these techniques, you have a fool for a chief engineer. The professional compilers such as IAR, Rowley, and Keil etc. are more efficient, generally bug free and interface seamlessly with debuggers. They allow debugging with either ram or flash executables and flash programming is usually accomplished with a single click. You also have telephone support with these systems. These professional packages save your company time and money in the long run.

This tutorial was written for students and grown up “kids at heart”; its purpose is to foster their interest in computer science and electrical engineering. It’s a shame that the big players like Microsoft, Kiel, Borland and others don’t develop a “student/hobbyist” version of their software development packages, priced at a give-away point that a third world high school student could afford. Bill Gates has criticized my country’s school system for not developing enough computer scientists and engineers; why not provide a

“non-commercial” version of his Visual Studio for students (and provide code targeting for every popular microprocessor being sold today)?

I am not happy with the debugger I described in the tutorial. The Wiggler/Eclipse CDT Debugger combination works only for RAM-based applications and thus limits software to less than 64K. It’s extremely slow and a bit unreliable. Professional USB or Ethernetbased debuggers are very expensive and out of the price range of hobbyists.

The world will beat a path to the first vendor that markets an inexpensive USB-based debugger for the ARM microprocessor. The new Philips LPC2148 ARM chip with onboard USB looks like the perfect vehicle for such an application. The ARM JTAG circuits allow two “hardware” breakpoints and this should be adequate for a student or hobbyist who wishes to debug flash-based applications. The “student” version of a ARM USB-based debugger could be just a little circuit board with a cheap wall-wart power supply. Olimex has a USB-based JTAG debugger project in the works, so we can all keep our collective fingers crossed that they will be successful.

I’m not finished writing tutorials. My next tutorial will involve using ARM interrupts and how to design and implement I2C port expanders to interface to LCD displays and keypads. Later tutorials will go into motion control, free real-time operating systems and other hardware projects. Stay tuned, just like you, I’m just getting started!

24 About the Author

Jim Lynch lives in Grand Island, New York and is a Project Manager for Control Techniques, a subsidiary of Emerson Electric. He develops embedded software for the company’s industrial drives (high power motor controllers) which are sold all over the world.

Mr. Lynch has previously worked for Mennen Medical, Calspan Corporation and the Boeing Company. He has a BSEE from Ohio University and a MSEE from State University of New York at Buffalo. Jim is a single Father and has two children who now live in Florida and Nevada. He has two brothers, one is a Viet Nam veteran in Hollywood, Florida and the other is the Bishop of St. Petersburg, also in Florida. Jim plays the guitar and is collecting woodworking machines for future projects that will integrate woodworking and embedded computers. Lynch can be reached via e-mail at: lynchzilla@aol.com

24 Some Books That May Be Helpful

The following is a short compendium of books that I’ve found helpful on the subject of ARM microprocessors and the GNU tool chain. I’ve reproduced the Amazon.com data on them.