1 OVERVIEW

This chapter contains the following sections:

Introduction
CrossView Pro's Features
Source Level Debugging
How CrossView Pro Works
8051 Program Development
Getting Started
Before Starting
Setting Up the Execution Environment
Starting CrossView Pro
CrossView Pro Target Settings
Configuring CrossView Pro
Loading Symbolic Debug Information
Executing an Application
Debugging an Application
CrossView Pro Output
Exiting CrossView Pro
What You May Have Done Wrong
Building Your Executable
Using EDE
Using the Makefile

1.1 Introduction

This chapter highlights many of the features and capabilities of CrossView Pro, including an Introduction to Source Level Debugging and the 8051 Development Environment.

This chapter also contains the section Getting Started, which shows you how to compile a program to work with the debugger.

1.2 CrossView Pro's Features

CrossView Pro is TASKING's high-level language debugger. CrossView Pro is a real-time, source-level debugger that lets you debug embedded microprocessor systems at your highest level of productivity. Its powerful capabilities include:

Multi-Window Interface

This interface uses your host's native windowing system, so that you already know how to open, close and resize windows. With windows you can keep track of information concerning registers, the stack, and variables. CrossView Pro automatically updates each window whenever execution stops.

You have great freedom in designing a suitable display. You can hide and resize the various windows if you choose.

Statement Evaluation

You can enter C expressions, CrossView Pro commands or any combination of the two for CrossView Pro to evaluate. You may also call functions defined in your source code from the command line. Expression evaluation is an ideal way to test subroutines by passing them sample values and checking the results.

Breakpoints

Breakpoints halt program execution and return control to you. There are several types of breakpoints: code, data, instruction count, cycle count, timer and sequence.

Code breakpoints let you halt the program at critical junctures of program execution and observe values of important variables.

You may place data breakpoints to determine when memory addresses are read from, written to, or both. With data breakpoints, you can easily track the use and misuse of variables.

An instruction count breakpoint halts the program after a specified number of instructions have been executed; a cycle count breakpoint stops the program after a number of CPU cycles; a timer breakpoint stops the program after a number of micro seconds or ticks and sequence breakpoints stop the program when a number of breakpoints are hit in a specified sequence.

Data breakpoints, instruction count breakpoints, cycle count breakpoints and timer breakpoints are not available for all execution environments, please check the Addendum.

Probe Point Breakpoints

A breakpoint can be treated as a probe point. When a probe point breakpoint is hit, the associated commands are executed and program execution is continued. Probe points are used with File I/O simulation and sequence breakpoints.

Assertions

A powerful assertion mechanism lets you catch hard-to-find-errors. An assertion is a command, or series of commands, executed after every line of source code. You may use assertions to test for all sorts of error conditions throughout the entire length of your program.

C-Trace

CrossView Pro has a separate window that displays the most recently executed C statements or machine instructions. This feature uses the execution environment's trace buffer along with symbolic information generated during compilation. This feature is depending on the execution environment.

I/O Simulation (IOS)

With I/O simulation you can debug programs without the actual input and output devices being present. CrossView Pro can read input data from the keyboard or a file, or can send output to a window or a file. You can view the data in several formats, including hexadecimal and character. You can have an unlimited number of simulated I/O ports, which can be associated with the screen and displayed in windows.

Data Monitoring

You may place variables and expressions in the Data window, where CrossView Pro updates their values when execution stops.

Single Stepping

With CrossView Pro, you can single step through your code at source level or at assembly level, into or over procedure calls. Running your program one line at a time lets you check variables and program flow.

Coverage

When a command such as StepInto or Continue executes the application, CrossView Pro traces all memory access, i.e. memory read, memory write and instruction fetch. Through code coverage you can find executed and non-executed areas of the application program. Areas of unexecuted code may exist because of programming errors or because of unnecessary code. It may be that your program input, your test set, is incomplete; It does not cover all paths in the program. Data coverage allows you to verify which memory locations, i.e. which variables, are accessed during program execution. Additionally, you can see stack and heap usage. The availability of this feature depends on the execution environment.

Profiling

Profiling allows you to perform timing analysis on your software. Two forms of profiling are implemented in CrossView Pro.

Function profiling, also called cumulative profiling, gives you timing information about a particular function or set of functions. CrossView Pro shows: the number of times a function is called, the time spent in the function, the percentage of time spent in the function, and the minimum/maximum/average time spent in the function. The timing results include the time spent in functions called by the profiled function.

Code range profiling presents timing information about a consecutive range of program instructions. CrossView Pro displays the time consumed by each line (source or disassembly) in the Source Window. Next to this, the Profile Report dialog shows the time spend in each function. The timing results do not include the time consumed in functions called by the profiled function.

The availability of profiling depends on the execution environment. Function profiling can be supported if the execution environment provides a clock that starts and stops whenever execution starts and stops. Code range profiling heavily relies on special profiling features in the execution environment. Normally code range profiling is only supported by instruction set simulators.

Macros

Macros let you store and recall complex commands and expressions with a minimal number of keystrokes. You can store macros in a "toolbox", making it possible to execute complex functions with the touch of a mouse button. You can also place macros in command lists of breakpoints and assertions. You can use flow control statements within macros, and macros can call other macros, allowing you to construct arbitrarily complex sequences. Macros can accept multiple parameters, be saved and loaded from files and can even rename existing CrossView Pro commands.

Record & Playback

At any time, you can record the commands you type, and optionally their output, to a file. You can also play back files of commands all at once or in a single-step playback mode. These functions are helpful for setting up standardized debugging tests or to save results for later study or comparison.

Kernel Support

CrossView Pro supports RTOS (Real-Time Operating System) aware debugging for various kernels. Since each kernel is different, the RTOS aware features are not implemented in the CrossView Pro executable, but in a library that will be loaded at run-time by CrossView Pro. The amount of windows and dialogs and their contents is kernel dependent.

On-Line Help

All the major windows and dialog boxes contain a Help button. Clicking on this button wherever it appears, or pressing the function key F1, opens the CrossView Pro help system at the appropriate section. From this point, you can also access the rest of the help system. The MS-Windows version of CrossView Pro uses the native help system.

Documentation

CrossView Pro has a comprehensive set of documentation for both new and experienced users. The manual includes an installation guide, description of debugging with CrossView Pro, error messages, and a command reference section. The documentation tries to cover a wide range of expertise, by making few assumptions about the technical experience of the reader.

1.3 Source Level Debugging

CrossView Pro is a source level debugger. Source level means that debugging works on the actual C code or assembly code. CrossView Pro can deal with global and local variables that are both statically and dynamically allocated variables. Therefore, it can deal with compiled addresses of variables that move around the stack. CrossView Pro knows the compiler's addressing conventions for variables of any type.

The Debugging Environment

All debugging configurations follow a similar pattern. There is a host system where the debugger runs, and a target system (usually an execution environment), where the program being debugged runs. There may also be a probe that can plug into the actual hardware of the embedded system being designed.

CrossView Pro provides a high-level interface between you, the user, working at the host system and a program running at the target system (execution environment). This means that you may issue commands that refer directly to the variables, source files, and line numbers as they appear in the source program. You can do this because CrossView Pro uses symbol information generated during compilation to translate the high-level commands that you type into a series of low level instructions that the target system understands. Using Generic Debug Instrument (GDI) calls towards a shared library for the simulator, or using a connection between the host and emulator, CrossView Pro finds out information about the state of the target program and then tells the target to perform the requested actions.

A host-target arrangement can perform functions beyond the reach of traditional software-based debuggers. Since the target contains the actual chip, CrossView Pro can observe its operations without interfering. The existence of CrossView Pro and the host is invisible to the target program. This means that the program under debug runs exactly the same as the final program will in a real embedded system (except for real-time situations like timings).

With CrossView Pro, you may also take advantage of any advanced capabilities of your target hardware through emulator mode (transparency mode). In transparency mode you can communicate with the target as if the host system were a terminal directly connected to the target. You can enter and leave transparency mode freely without restarting the debugger or the target system. CrossView Pro therefore does not interfere with the normal operation of the target hardware. Thus the debugger is a powerful accessory to the machine-level debugging that you might do with the target system alone. The transparency mode is not available for all execution environments.

1.4 How CrossView Pro Works

Although it is not necessary to know how CrossView Pro performs its debugging, you may be curious how CrossView Pro works.

Whenever you enter a debugger command, CrossView Pro obtains information from or controls the execution environment by sending appropriate commands over the host-target link. A typical session may go something like this:

1. Highlight initval and click on the Show Expression button in the Source Window.

Figure 1-1: Show selected source expression

2. CrossView Pro converts this action into a command. Depending on preferences you have set, the variable is shown in the Data Window or the Expression Evaluation dialog is shown.

3. CrossView Pro consults the symbol table to deduce the type and address of initval. Suppose initval is a variable of type int which lies at absolute location 100.

4. The debugger forms a command asking the target system to read two bytes starting at address 100 (the size of an int equals 2).

5. CrossView Pro then transmits the command to the target system and receives the response.

6. CrossView Pro interprets the response, and for example determines that initval equals 17.

7. CrossView Pro then displays initval=17 since it knows initval's type.

Figure 1-2: CrossView Pro Command Output

This is a simplified example, many CrossView Pro commands require several complex transactions, but all take place without you being aware of them.

1.5 8051 Program Development

The CrossView Pro debugger package is part of a toolchain that provides an environment for modular program development and debugging. The figure below shows the structure of the toolchain. The toolchain contains the following programs:

cc51 The C cross-compiler which translates a C source program into a highly optimized assembly source file.

mpp51 A string-macro preprocessor allowing macro substitution, file inclusion and conditional assembly, according to the Macro Preprocessor Language.

asm51 The assembler program which produces an object file from a given assembly file.

link51 A linker/locator combining objects and object libraries into one target load file.

ar51 A librarian program, which can be used to create and maintain object libraries.

ieee51 A program which formats an absolute (located) TASKING a.out file to the IEEE-695 format which has full high level language debugging support. The IEEE-695 format is used by CrossView Pro.

ihex51 A formatter to translate an absolute (located) TASKING a.out file into Intel Hex Format for (E)PROM programmers. No symbol information.

omf51 A formatter to translate an absolute (located) TASKING a.out file into absolute OMF51 format.

srec51 A formatter to translate an absolute (located) TASKING a.out file into Motorola S Format for (E)PROM programmers. No symbol information.

dmp51 A utility to display the contents of an object file.

mk51 A program builder which uses a set of dependency rules in a 'makefile' to build only the parts of an application which are out of date.

xfw51 The CrossView Pro debugger using 8051 execution environments.

Figure 1-3: 8051 development flow

For a full description of all available formatter programs and other utility programs see the chapter Utilities in the 8051 Cross-Assembler, Linker, Utilities User's Guide.

1.6 Getting Started

1.6.1 Before Starting

Before using CrossView Pro, there are several things that you must do:

For the purpose of getting you started quickly, we have supplied you with a demo program that you can debug. The demo program is sim.abs.

1.6.2 Setting Up the Execution Environment

The following only applies to ROM monitor and emulator versions of CrossView Pro.

In order for the host and execution environment to communicate, a proper connection must exist between the two machines. Here are some important considerations:

1.6.3 Starting CrossView Pro

To invoke CrossView Pro, simply double-click on its icon. CrossView Pro starts up and opens the command window, source window and other windows.

Figure 1-4: Command Window

CrossView Pro can be passed the name of an execution (*.abs) file. This can be done from a command line, but the native windowing system often provides alternatives. Usually this involves dragging the program to be debugged onto the CrossView Pro executable from the Windows Explorer for Windows 95/98/NT/2000, and dropping it there or associating CrossView Pro to be the application to start when double-clicking an .abs icon. CrossView Pro will start and load the symbol information from that file.

1.6.3.1 CrossView Pro Target Settings

You can specify specific CrossView Pro startup settings in the Target Settings dialog.

To open the Target Settings dialog:

Figure 1-5: CrossView Pro Target Settings

You can set the following items in this dialog:

Target Configuration

The available targets are described by the target configuration files (*.cfg in the etc subdirectory). The target configuration files are text files and can be edited with any text editor.

Empty lines, lines consisting of only white space are allowed. Comment starts at an exclamation-sign ('!') and ends at the end of the line.

An information line has the following synopsis:

field one of the keywords described below

field-value the value assigned to the field

comment optional comment

The fields listed in the configuration file are:

Field Description
title The full name of the configuration. This name will be displayed in the Target configuration field of the Target | Settings dialog.
cpu_type The name of the CPU.
debug_instrument_module The name of the Debug Instrument (using GDI) used for debugging: 'sim51' for the instruction set simulator, 'rom51' for TASKING ROM monitor and 'rism51' for the RISM51 ROM monitor.
radm The name of the Debug Instrument (using KDI) used for RTOS aware debugging. (optional).

Notes:

1.6.3.2 Configuring CrossView Pro

You may have to configure CrossView Pro to talk to the emulator or ROM monitor. If you have a simulator version this step is not needed and the associated menu item is grayed. To configure CrossView Pro:

Figure 1-6: Setting up CrossView Pro Communications

From EDE you can set the communication parameters in the CrossView Pro | Communication entry of the Project | Project Options... dialog.

1.6.3.3 Loading Symbolic Debug Information

You must tell CrossView Pro which program that you want to debug. To do this:

CrossView Pro remembers all previously saved settings. In this case, the Load Symbolic Debug Info dialog already contains the previously saved configuration, so you only have to click the Load button to perform your actions.

Figure 1-7: Loading Symbolic Debug Information

Compare Application

You can use the File | Compare Application... dialog to check if a file matches the downloaded application. This can be useful when your program has changed some of your code.

1.6.4 Executing an Application

To view your source while debugging, the Source Window must be open. To open this window,

Before starting execution you have to reset the target system to its initial state. The program counter, stack pointer and any other registers must be set to their initial value. The easiest way to do this is:

Depending on your execution environment a target system reset may have undesired side effects. For this reason, the target system reset is executed before the code is downloaded to the target.

If you have not checked these items:

The first single step executes the startup code and stops at the first line of code in main(). You should see your program's source code.

Another way of getting there is:

To set a breakpoint you can:

Figure 1-8: Getting Control

Now it is time to execute your program:

In the Source Window the current execution position (i.e. the statement at the address identified by the current value of the program counter) is higlighted in blue. As a result, when execution stops, the line you set a breakpoint on is highlighted. You can now single step through your program using the Step Into and Step Over buttons in the Source Window. Or you may choose to execute the rest of the program (or at least until the next breakpoint) with the Run button.

At any point you can interrupt the emulator and regain control by clicking on the Halt button in either the Source Window or the Command Window.

For more information on executing a program, see Chapter 5, Controlling Program Execution.

1.6.5 Debugging an Application

When debugging your application you probably want to see the calling sequence of your program, and inspect the contents of variables and data structures used within your program.

To see the calling sequence of your program the Stack Window must be open. The stack window shows the functions that are currently on the stack. To open the stack window,

To see the value of the local variables of a function,

Figure 1-9: Watch variables

To inspect the value of global variables and data structures,

Depending on preferences you have set, the variable is shown in the Data Window as shown in figure 1-9 or the dialog displayed in figure 1-10 is shown.

Figure 1-10: Expression evaluation

Pointers, structures and arrays displayed in the data window have a compact and expanded form. The compact form for a structure is just <struct>, while the expanded form shows all the fields. The compact form of a pointer is the value of the pointer, while the expanded form shows the pointed-to object. The compact form is indicated by putting a '+' at the start of the display. (i.e., the object is expandable), while a '-' indicates the expanded form (i.e., the object is contractible). Nesting is supported, so structures within structures can likewise be expanded, ad infinitum.

To expand a pointer, structure or an array:

1.6.6 CrossView Pro Output

Nearly every CrossView Pro command can be given using the graphical user interface. These commands and the debugger's response is logged in the Command Output Window which is the upper part of the Command Window. Alternatively, CrossView Pro commands can be entered directly (without using the menu system) in the command edit field of the command window.

To open the Command Window:

Figure 1-11 shows an example of the Command Window. Commands can be typed into the command edit field (bottom field) or selected from the command history list (middle field) and edited then executed. The top field is referred to as the Command Output Window. Each command, echoed from the command edit field, is displayed with a '>' prefix. CrossView's response to the command is displayed below the command.

Figure 1-11: CrossView Pro Command Output

You can choose to clear the command edit field after executing a command. Choose the File | Options... menu item and select the Desktop tab. Enable the Clear command line after executing command check box. You can use the clear command to clear the Output Window.

1.6.7 Exiting CrossView Pro

To quit a debugging session:

If you selected one or more items in the Options dialog, your settings will be saved in the initialization file xvw.ini. This file is located in the startup directory.

Workspace files

If you have set the Save desktop and target settings check box in the Save tab, CrossView Pro will create a workspace file (.cws) for each debugged or loaded application. The settings will be restored in a following debug session. If CrossView Pro cannot find a workspace file for a loaded application it uses the default workspace file xvw.cws in the etc directory.

A CrossView Pro workspace file contains:

1.6.8 What You May Have Done Wrong

Most problems in starting up CrossView Pro for a debugging session stem from improperly setting up the execution environment or from an improper connection between the host computer and the execution environment. Some targets will require you to enter transparency mode to set the execution environment for a debugging session. Check the notes for your particular execution environment.

Here are some other common problems:

1.6.9 Building Your Executable

The subdirectory xvw in the examples subdirectory contains a demo program for the 8051 toolchain.

In order to debug your programs, you will have to compile, assemble, and link them for debugging using the TASKING 8051 tools. You can do this with EDE, the Embedded Development Environment (which uses a project file and a makefile) or you can call the makefile from the command line.

1.6.9.1 Using EDE

EDE stands for "Embedded Development Environment" and is the MS-Windows oriented Integrated Development Environment you can use with your TASKING toolchain to design and develop your application.

To use EDE on the demo program, located in the subdirectory xvw in the examples subdirectory of the 8051 product tree, follow the steps below.

A detailed description of the process creating the sample program sim.abs is described below. This procedure is outlined as a guide for you to build your own executables for debugging.

The dialog boxes shown in this manual serve as an example. They may slightly differ from the ones in your product.

How to Start EDE

You can launch EDE by double-clicking on the EDE shortcut on your desktop.

The EDE screen provides you with a menu bar, a toolbar (command buttons) and one or more windows (for example, for source files), a status bar and numerous dialog boxes.

How to Select a Toolchain

EDE supports all the TASKING toolchains. When you first start EDE, the correct toolchain of the product you purchased is selected and displayed in the title of the EDE desktop window.

If you have more than one TASKING product installed and you want to change toolchains, do the following::

1. From the Project menu, select Select Toolchain...

The Select Toolchain dialog appears.

2. Select the toolchain you want. You can do this by clicking on a toolchain in the Toolchains list box and click OK.

If no toolchains are present, use the Browse... or Scan Disk... button to search for a toolchain directory. Use the Browse... button if you know the installation directory of another TASKING product. Use the Scan Disk... button to search for all TASKING products present on a specific drive. Then return to step 2.

How to Open an Existing Project

Follow these steps to open an existing project:

1. From the Project menu, select Set Current ->.

2. Select the project file to open. For the demo program select the file sim.pjt, located in the subdirectory xvw in the examples subdirectory of the 8051 product tree. If you have used the defaults, the file sim.pjt is in the directory c:\cc51\examples\xvw.

How to Load/Open Files

The next two steps are not needed for the demo program because the files addone.src and demo.c are already open. To load the file you want to look at:

1. From the Project menu, select Load Files...

The Choose Project Files to Edit dialog appears.

2. Choose the file(s) you want to open by clicking on it. You can select multiple files by pressing the <Ctrl> or <Shift> key while you click on a file. With the <Ctrl> key you can make single selections and with the <Shift> key you can select everything from the first selected file to the file you click on. Then click OK.

This launches the file(s) so you can edit it (them).

Check the directory paths

1. From the Project menu, select Directories....

The Directories dialog appears.

2. Check the directory paths for programs, include files and libraries. You can add your own directories here, separated by semicolons.

3. Click OK.

How to Build the Demo Application

The next step is to compile the file(s) together with its dependent files so you can debug the application.

Steps 1 and 2 are optional. Follow these steps if you want to specify additional build options such as to stop the build process on errors and to keep temporary files that are generated during a build.

1. From the Build menu, select Options...

The Build Options dialog appears.

2. Make your changes and press the OK button.

3. From the Build menu, select Scan All Dependencies.

4. Click on the Execute 'Make' command button. The following button is the execute Make button which is located in the toolbar.

If there are any unsaved files, EDE will ask you in a separate dialog if you want to save them before starting the build.

How to View the Results of a Build

Once the files have been processed you can inspect the generated messages in the Build tab:

TASKING program builder vx.yrz   Build nnn SN 00000000
Compiling demo.c
Assembling demo.src
Assembling addone.src
Macro preprocessing sim_cstart.asm
Assembling sim_cstart.src
Linking to sim.out
Creating IEEE-695 absolute file sim.abs

How to Start the CrossView Pro Debugger

Once the files have been compiled, assembled, linked, located and formatted they can be executed by CrossView Pro.

To execute CrossView Pro:

1. Click on the Debug application button. The following button is the Debug application button which is located in the toolbar.

CrossView Pro is launched. CrossView Pro will automatically download the compiled file for debugging.

How to Start a New Project

When you first use EDE you need to setup a project space and add a new project:

1. From the File menu, select New Project Space...

The Create a New Project Space dialog appears.

2. Give your project space a name and then click OK.

The Project Properties dialog box appears.

3. Click on the Add new project to project space button.

The Add New Project to Project Space dialog appears.

4. Give your project a name and then click OK.

The Project Properties dialog box then appears for you to identify the files to be added.

5. Add all the files you want to be part of your project. Then press the OK button. To add files, use one of the 3 methods described below.

The new project is now open.

6. From the Project menu, select Load Files... to open the files you want on your EDE desktop.

EDE automatically creates a makefile for the project. EDE updates the makefile every time you modify your project.

1.6.9.2 Using the Makefile

The subdirectories in the examples directory each contain a makefile which can be processed by mk51. Also each subdirectory contains a readme.txt file with a description of how to build the example.

To build the demo example follow the steps below. This procedure is outlined as a guide for you to build your own executables for debugging.

1. Make the subdirectory xvw of the examples directory the current working directory.

This directory contains a makefile for building the demo example. It uses the default mk51 rules.

2. Be sure that the directory of the binaries is present in the PATH environment variable.

3. Compile, assemble, link and locate the modules using one call to the program builder mk51:

This command will build the example using the file makefile.

To see which commands are invoked by mk51 without actually executing them, type:

To remove all generated files type:


Copyright © 2002 Altium BV