11 SPECIAL FEATURES

This chapter contains the following sections:

Transparency Mode

RTOS Aware Debugging

Coverage

Profiling

Data Analysis
Supplied Data Analysis Window Scripts
Syntax of CrossView eXtension Language (CXL)

Background Mode
Configuration
Entering Background Mode
Leaving Background Mode
The Stack in Background Mode
Local and Global Variables
Refresh Limitation
Assertions

11.1 Transparency Mode

Transparency mode allows you to communicate directly with the execution environment. Most of the time CrossView Pro will handle all the low level communications, freeing you to concentrate on the high level C code. Depending on the type of execution environment, however, you may have to enter transparency mode to set up the execution environment when the machine is first turned on.

To enter transparency mode:

Select the View | Command | Emulator menu item.

All commands entered in the Emulator Command Window are passed directly to the execution environment.

To exit transparency mode:

Select the View | Command | CrossView menu item.

In CrossView Pro, you can pass a string directly to the execution environment without leaving CrossView Pro with the o command:

This passes the command map directly to the execution environment, while you remain in CrossView Pro. Naturally you will have to learn your execution environment's command set to make use of the o command.

FUNCTION: Pass a command to the execution environment.

COMMAND: o string

Do not issue one-shot transparency commands that result in large output (or otherwise require intervention other than a carriage return to terminate output). Instead, enter transparency mode first, then issue the command.

You may also enter transparency mode upon startup with the -T option. See the section on startup options.

11.2 RTOS Aware Debugging

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.

Within the CrossView Target Settings dialog (Target | Settings...), select the CrossView Pro configuration you will use by selecting a "Target configuration". These target configuration files are normal ASCII text files. The name of the shared library that contains the kernel aware code can be specified in the target configuration. The "radm" configuration item specifies the name of the shared library that contains the kernel aware code.

The syntax of a target configuration file is:

[! comment] field : field-value

field one of the defined keywords

field-value the value assigned to the field

comment optional comment

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

The line for the shared library that supports RTOS aware code could be:

11.3 Coverage

You can only use this feature if it is supported by the execution environment (see the addendum).

When the application program is executed as a result of a command such as StepInto or Continue, CrossView Pro traces all memory access, i.e. memory read, memory write and instruction fetch. Through code coverage, executed and not execute areas of the application program can be found. Areas of unexecuted code may exist in case of programming errors or simply dead code which could be eliminated. Alternatively, 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, stack and heap usage can be shown.

To enable/disable coverage:

Select the Tools | Coverage checked menu item.

When the menu item is checked, coverage is enabled. Select the menu item again to disable coverage.

Type the ce or cd command on the command line:

FUNCTION: Enable coverage.

COMMAND: ce

FUNCTION: Disable coverage.

COMMAND: cd

Two dialogs are present to give you coverage information. The code coverage dialog shows the percentage of executed code within application, module and function scope. Code coverage information can also be displayed in the Source Window. The data coverage dialog shows the data access of HLL variables in the executed program. Data coverage can also be displayed in the Memory Window. The coverage dialogs can be opened via the Tools menu.

FUNCTION: List coverage information to output window or file.

COMMAND: covinfo [[all | module_or_function_name][ ,filename]]

You can display code coverage information in the Source Window by clicking on the Coverage button in the Source Window. In this case an extra column appears to the right of the breakpoint toggles (to the left of the source line). For each source code line that is executed (covered), the source line is marked. The not executed lines are not marked. CrossView Pro has special commands to move the cursor to the next or previous covered or uncovered line:

FUNCTION: Move cursor to next covered line.

COMMAND: nC

FUNCTION: Move cursor to next uncovered line.

COMMAND: nU

FUNCTION: Move cursor to previous covered line.

COMMAND: pC

FUNCTION: Move cursor to previous uncovered line.

COMMAND: pU

You can display data coverage information in the Memory Window by clicking on the Code Coverage button in the Memory Window. Besides the current value of memory locations, the memory window also displays whether memory locations have been accessed during program execution. An application program may read from, write to, or fetch an instruction from a memory location. Of course all combinations may be legal. Although writing data to a memory location from which an instruction has been fetched is suspicious. All types of accesss, read, write, fetch or combinations of these, can be shown using different foreground and background colors. The color combination used to show "rwx" access are specified in the Desktop tab of the File | Options... menu item. It is advised to change the background color if instructions are fetched from a memory location, and to change the foreground color to show read and write access.

11.4 Profiling

You can only use this feature if it is supported by the execution environment (see the addendum).

Profiling allows you to perform timing analysis on your software. Two forms of profiling are implemented in CrossView Pro. Both forms of profiling are fully implemented in the CrossView Pro debugger. You do not have to recompile your source code to enable the profiling features.

Function profiling, also called cumulative profiling, gives timing information about a particular function or set of functions. The time spent in functions called by the function being profiled is included in the timing results. Within the Cumulative Profiling Setup dialog you select one or more functions to be profiled. The gathered profile is shown in the Cumulative Profiling Report dialog. For each function the number of calls, the minimum/maximum/average and total time spent in the function are shown. Also, the relative amount of time consumed by a function in respect to the time consumed by the application is shown.

Function profile data is gathered whenever the program is executed using the Continue command (not single stepped). Function profiling can be supported if the execution environment provides a clock that starts and stops whenever execution starts and stops. Basically function profiling is implemented by using a special type of breakpoint. Breakpoints are inserted at the function entry address and all it's return addressed. Whenever execution stops due to a profile-breakpoint hit, CrossView Pro will read the clock, update the internal profile tables, and restart execution.

To specify the functions to be profiled:

Select the Tools | Cumulative Profiling Setup... menu item.

Type the cproinfo command on the command line:

To view the profiling results:

Select the Tools | Cumulative Profiling Report... menu item.

Type the cproinfo command on the command line:

FUNCTION: List cumulative profining results to output window or file, or add or remove functions from the list of profiled functions.

COMMAND: cproinfo [all[,filename] | {add | remove } function]

Code range profiling presents timing information about a consecutive range of program instructions. CrossView Pro displays the time consumed by each statement, C or assembly, in the source window. The timing data can be displayed in three different formats: absolute, relative to program, and relative to function. To change the display format: position the cursor on the profile column and click the right mouse button. Select the appropriate format from the popup menu.

Next to the source window, the profile report dialog (Tools | Profiling Report...) shows the time spent in each function. The time consumed by functions called from the function being profiled is not included in the displayed time.

FUNCTION: List profile information to output window or file.

COMMAND: proinfo [[all | module_or_function_name][ ,filename]]

Code range profiling data is gathered whenever the program is executed. It does not matter if the program executes due to a continue, step-over or step-into command. Code range profiling heavily relies on special profiling features in the execution environment. Normally code range profiling is only supported by instruction set simulators.

To enable/disable profiling:

Select the Tools | Profiling checked menu item.

When the menu item is checked, code range profiling is enabled. Enabled means that the execution environment starts gathering profiling data. Select the menu item again to disable profiling.

Type the pe or pd command on the command line:

FUNCTION: Enable profiling.

COMMAND: pe

FUNCTION: Disable profiling.

COMMAND: pd

Select the Profiling button in the Source Window to display profile data in the Source Window. If profiling is not enabled, this button also starts gathering of profiling data.

Normally both function and code range profiling will slow down the execution speed of the application being debugged. Therefore, switch off profiling whenever the timing information is not required.

CrossView Pro uses the TriCore synchonization instructions DYNC and ISYNC each time execution is halted to guarantee the ordering of various events within the machine. For accurate cycle counting turn off this feature.

To turn off synchronization on halt

From EDE:

1. From the Project menu, select CrossView Pro Options...

The TriCore CrossView Pro Debugger Options dialog appears.

2. Select the Miscellaneous tab.

3. Disable the Synchronize on Halt check box.

4. Click OK.

On the command line use the following option:

11.5 Data Analysis

CrossView Pro incorporates an advanced signal analysis interface designed to enable developers to monitor signal data more critically and thoroughly. This feature is useful when developing signal processing software for application areas such as communication, wireless and image processing.

The Data Analysis window (as shown in figure 4-15 ) is used for this purpose. This window is opened as result of processing a data analysis script (CXL script) and is only updated on user request. TASKING provides scripts for standard signal analysis such as x-t plotting, x-y plotting, FFT power spectrum, FFT waterfall, combined FFT power spectrum and phase, and eye diagram. However, the programmer can write CXL scripts and process the data in the format he desires.

Refer to the CXL syntax specification in section 11.5.2 for details.

Four processes are associated with the graph window:

1. Get raw data

2. Transform data

3. Generate representation

4. Draw

The get raw data process retrieves data from the target and stores the data at the host system in one or more CrossView Pro internal acquisition data buffers. Since these buffers reside on the host system it is possible to maintain a history of data.

The transform data process takes the raw data as input, processes it, and the result of the transformation, a set of (x, y) pairs, is saved in the processed data buffer associated with a window. Since the transformations are described in CXL (CrossView eXtension Language) the user can program the data transformation that is of most interest for him. For example, an FFT power spectrum would produce (frequency, power) pairs.

The generate representation process takes data from the processed data buffer, (x, y) pairs, as input and generates a display list. This process scales the data according to the given display window size. This process is coded in CXL. So, in addition to the scripts provided by TASKING, the user can write his own representation processes. For example, an FFT power spectrum is usually represented by a bar graph.

The drawing engine process takes the display list as input and produces the graph that is displayed in the Data Analysis window. The drawing engine is part of the CrossView Pro executable and cannot be configured by the user.

A clear separation between data transformation (the transform data process) and data presentation (generate representation process) has been made to increase the reusability of complex data presentation scripts.

Once the scripts are written (a number of frequently used operations are supplied), the following three steps must be made in order to display data:

1. Set the display mode for the desired window using the graphm command. For example,

"demo" will be shown in the title bar of the window. It is also the name used to refer to the window.

2. Retrieve data from the target into a buffer using the memget command. For example,

$i is the "iterator" to walk 128 times through the expression (Note: the retrieved elements are assumed to be equidistantly placed in memory) and store the results in $buffer.

Optionally the buffer contents can be appended to another buffer using the bufa command, in order to maintain a (limited) history. For example,

3. Transform the buffer contents to displayable data using the graph command. For example,

For details of the arguments provided to x_t.cxl, see below. Now a used buffer can be freed using the bufd command (if the target data is not to be used anymore).

Steps 1. and 2. can be repeated as many times as desired. The display mode can be changed at any time by issuing a graphm command for the window to be changed. Using the graphp command, a window can be positioned anywhere on the screen.

11.5.1 Supplied Data Analysis Window Scripts

The following scripts and commands are described for completeness. Normally, you will not use the commands directly, because they are automatically invoked when you click OK in the Data Analysis Window Setup dialog.

For some graphm scripts both x- and y-axis can be user specified. If the limits are not specified or low >= high, then autoscaling is used.

X-T plotting

An x-t plot is the most straightforward way of displaying data. Data is taken from one buffer, each value is taken as the x value and the t value is increasing linearly. It is displayed as a graph the way it is found in the buffer (memory). The layout of the scales and the form of the graph (line, bar, dot) can be selected as shown below.

1. Generating window data pairs:

graph "win_title", "x_t.cxl", $buffer, t_offset, t_increment

generates (t, x) pairs: (t_offset + i * t_increment, $buffer[i]). The generated data is attached to the specified window.

2. Setting the display mode:

graphm "win_title", "show_x_t.cxl" [, low_x, high_x [, low_y, high_y ] ]

displays lines drawn between successive coordinates specified by the window data pairs.

graphm "win_title", "show_cross.cxl" [, low_x, high_x [, low_y, high_y ] ]

displays 'x's at the coordinates specified by the window data pairs.

graphm "win_title", "show_plus.cxl" [, low_x, high_x [, low_y, high_y ] ]

displays '+'s at the coordinates specified by the window data pairs.

graphm "win_title", "show_bars.cxl" [, low_x, high_x [, low_y, high_y ] ]

displays bars at the coordinates specified by the window data pairs. The x-coordinates are expected to be equidistant.

X-Y plotting

An x-y plot takes values from two buffers, one from each at a time. The first is interpreted as the x-value, the second as the y-value of a point to display. No further processing is done on these values. The most common display mode is 'x's or '+'s (show_cross.cxl, show_plus.cxl, see previous description) to give a scattergram. The values can also be interconnected in order (show_x_y.cxl) to create Lissajous-like displays.

1. Generating window data pairs:

graph "win_title", "x_y.cxl", $x_buffer, $y_buffer

2. Setting the display mode:

graphm "win_title", "show_x_y.cxl" [, low_x, high_x [, low_y, high_y ] ]

draws lines from all (x[i], y[i]) to (x[i+1], y[i+1]). When autoscaling is active, some space is reserved on both x- and y-axis.

FFT power spectrum

The FFT power spectrum plot takes a buffer of arbitrary size to compute the power of all frequencies present in the signal (in decibels). If the buffer size is not a power of two, it will expand its input set to the next higher power and augment it with zeroes. To handle non-recurrent data correctly, several window functions can be applied in the process. If no reference level is given the maximum level is calculated and set to be 0 dB. The usual display mode is bars, although all x-t display methods can be used. The horizontal axis is in frequency steps, the vertical axis in decibels.

1. Generating window data pairs:

graph "win_title", "fft.cxl", $buffer, filter_index, frequency_step[,ref_level]

generates pairs ( i * frequency_step, log_power[i] ). The filter_index specifies one of the following FFT windowing functions:
0 rectangular
1 triangular
2 Hanning
3 Blackman-Harris

ref_level is the 0 dB reference level.

2. For displaying the generated pairs, any of the x-t plotting display scripts can be used. "show_bars.cxl" is recommended.

Multi FFT power spectrum ("waterfall")

The multi FFT power spectrum displays a chronilogical series of FFT power spectra. This diagram is also known as FFT waterfall. The FFT power spectrum plot takes a buffer of arbitrary size and splits it up in a number of frames of size 2two_exp. You can specify the overlap between successive frames. The overlap can be negative indicating gaps between successive frames. For each frame, the power (in decibels) of all frequencies present in the signal is computed.

1. Generating window data pairs:

graph "win_title", "multi_fft.cxl", $buffer, filter_index, frequency_step, two_exp[,overlap[,ref_level]]

generates pairs ( i * frequency_step, log_power[i] ). The filter_index specifies one of the following FFT windowing functions:

0 rectangular
1 triangular
2 Hanning
3 Blackman-Harris

2two_exp is the width of one single frame in number of input samples. two_exp must be a value between 2 and 14 (inclusive). If the input buffer does not contain enough samples to fill the last frame, the frame is completed with zeros.

overlap is the number points shared by successive frames. When negative, a 'gap' will occur between processed points. The first sample taken from the input buffer of frame N is equal to the first sample of frame N + 2two_exp - overlap. overlap must be smaller than 2two_exp.

ref_level is the 0 dB reference level.

2. For displaying the generated pairs, the display script "show_multi_bars.cxl" is required.

Multi FFT power spectrum in lines

Displays the same multi FFT power spectrum, but now in lines instead of bars. Here a 3D graph is shown. The script name is show_multi_lines.cxl.

Multi FFT power spectrum in lines and grid

Displays the same multi FFT power spectrum as the multi lines spectrum.. Now each point on a curve is interconnected with a point with the same x-coordinate of the previous graph. What you see here is a 'grid' with the values. The script name is show_multi_grid.cxl.

Use of colors in Multi FFT power spectrum

For all three graphm scripts show_multi_bars.cxl, show_multi_lines.cxl and show_multi_grid.cxl an optional third parameter can be added to set the color offset value. This allows you to create a dynamic display in which the color of each curve remains the same. The color offset can range from 0 to the maximum number of colors, and the maximum number of colors is the number of curves to be plotted. When the color offset exceeds the number of colors, the modulo will be taken; if it is negative it will be set to zero. The colors selected for the curves are spread evenly over the color spectrum. The number of colors can also be set as an (optional) fourth parameter of the script.

An example of a command file for a running script can be:

/* INITIALIZE */
rst           /* Rerun the program when the script is executed */
$fast_mode=2  /* If on the simulator, go to fast mode          */
s             /* Step to the main() routine to allow access    */
              /* to the output[] array.                        */
memget output[$i],256,$t  /* It's clear now.  */
bufa $f,$t,4096  /* Construct an empty time domain history     */
bufa $f,$t,4096
bufa $f,$t,4096
bufa $f,$t,4096
bufa $f,$t,4096
bufa $f,$t,4096
bufa $f,$t,4096
bufa $f,$t,4096
$color=0   /* Initialize the $color variable to track the graphs */

/* DEFINE THE TIME DOMAIN WINDOW */
graphp "Output time domain",50,25,716,295 /* set window position */
graphm "Output time domain","show_x_t.cxl"   /* set draw method  */
graph  "Output time domain","x_t.cxl",$t,0,1  
    /* use the 't' buffer */

graph_clear_updates "Output time domain"
    /* Set 'Output time domain' window update actions:           */
graph_add_update "Output time domain",memget output[$i],256,$t
    /* Get new time domain data from output[] into $t buffer     */
graph_add_update "Output time domain",graph "Output time domain","x_t.cxl",$t,0,1
    /* This command recalculates and redraws the window          */
/* DEFINE THE FREQUENCY DOMAIN WINDOW   */
graphp "Output freq domain",50,350,716,295                              /* set window position              */
graphmn "Output freq domain","show_multi_grid.cxl",-120,5,($color)
    /* set draw method                  */
graph "Output freq domain","multi_fft.cxl",$f,0,1,256
    /* use the 'f' buffer               */
graph_clear_updates "Output freq domain"
    /* Set 'Output freq domain' window update actions:          */
graph_add_update "Output freq domain", bufa $f,$t,4096 
    /* Add new data to buffer, max size 4096 (purging oldest)   */
graph_add_update "Output freq domain", $color = ($color+1) % 16
    /* 4096/256 = 16 graphs, increment color offset to follow   */
graph_add_update "Output freq domain", graphmn "Output freq domain","show_multi_grid.cxl",-120,5,($color)
    /* Use the graphmn command to avoid double redraws          */
    /* Place $color in braces to avoid confusion with buffers   */
graph_add_update "Output freq domain",graph "Output freq domain","multi_fft.cxl",$f,0,1,256
    /* This command recalculates and redraws the window         */

/* PLACE COMPLEX BREAKPOINT, HAVE IT UPDATE THE GRAPHICAL DATA WINDOWS  */
main#141 bi { update! "Output time domain"; update! "Output freq domain"; C }

/* CONTINUE RUNNING THE PROGRAM */
C

For passing the parameter $color, the command interpreter requires parentheses around it, otherwise it is interpreted as a buffer.

Combined FFT power spectrum and phase

The combined FFT power spectrum and phase plot adds a display of the phase of each component to the FFT power spectrum. The phase is normalized between -180 degrees and +180 degrees. To display both features of the input data a special display script must be used (show_fft_pairs.cxl).

1. Generating window data pairs:

graph "win_title", "fft_pairs.cxl", $buffer, filter_index, freq_step[,ref_level]

The filter_index specifies one of the following FFT windowing functions:
0 rectangular
1 triangular
2 Hanning
3 Blackman-Harris

ref_level is the 0 dB reference level.

2. Setting the display mode:

For displaying the generated display list, the display script "show_fft_pairs.cxl" is required.

graphm "win_title", "show_fft_pairs.cxl" [, min_power, max_power ]

Eye diagram

The eye diagram is a recurrent x-t plot. The input data is not processed, but the time parameter is reset when the signal crosses the trigger level, and also after a specified interval (wrap_limit). After crossing trigger_level, retriggering is suppressed during the trigger_hold_off next data values. The eye diagram uses the X-t plot method and exploits the feature of suppressing the fly-back of the displayed line.

1. Generating window data pairs:

graph "win_title", "eye.cxl", $buffer, wrap_limit [,t_increment [, t_offset
[, trigger_level [, trigger_hold_off]]]]

2. Setting the display mode:

graphm "win_title", "show_x_t.cxl" [, low_x, high_x [, low_y, high_y ] ]

displays lines drawn between successive coordinates specified by the window data. If x[i+1] < x[i] (going back in time), no line is drawn from (x[i], y[i]) to (x[i+1], y[i+1]), which can be regarded as the fly-back suppression in an oscilloscope.

11.5.2 Syntax of CrossView eXtension Language (CXL)

CXL has a C-like syntax, the basic differences from C are:

if (x < 0 )
x = 0;

if (x < 0 )
{
x = 0;
}

int i = 1;

int i;
... possible other variable declarations ...
i = 1;

Furthermore, the syntax is like the C syntax.

Example:

This example would print the following output in the command window:

Base Types

CXL supports the following base types:

Internally, char, int and long are treated the same, as are float and double. Since they are the same, types belonging to one group can be interchanged freely.

Pointer to base type is only supported for parameters not for other variables. Pointers to variables are the result of the "address-of" operator and are treated as arrays of the mentioned base type with upper-bound 1.

A return value can be of any base type. Data type void is also a valid return type.

Compound Types

CXL supports the following compound types:

Structures, unions and type definitions are not part of the CXL syntax.

Predefined Functions

1. Mathematical functions:

double sin(double x);
double cos(double x);
double tan(double x);
double acos(double x);
double asin(double x);
double atan(double x);
double sinh(double x);
double cosh(double x);
double tanh(double x);
double log(double x);
double log10(double x);
double exp(double x);
double sqrt(double x);
double ceil(double x);
double floor(double x);
double fabs(double x);
double pow(double x, double y);

2. Functions to send output to the command window:

double outc(double x);  -> { printf("%c", (int) x); return x; }
double outd(double x);  -> { printf("%ld", (long) x); return x;}
double outf(double x);  -> { printf("%f", x); return x; }

3. Upperbound of an array:

long upperbound(array a);

4. GUI interaction functions available when a script is passed to the graph command::

void add_point(double x, double y);

This function adds graph points to the acquisition buffer.

void printf(string format, ...);

The output of printf is written to the command window.

5. GUI interaction functions available when a script is passed to the graphm command::

void printf(string format, ...);

The output of printf is sent to the "window contents script".

This at first sight strange function name of printf is chosen to facilitate development and debugging graphm scripts using a host system C development environment. The C code can be very easily ported to CXL afterwards. The output is in fact a command of the drawing engine and is therefore not the same as a usual printf and no the same as printf in the graph command. Logging to the command window from a graphm script is not possible via printf.

The following drawing commands are supported:

clear

graph_area x-offset, y-offset, x-size, y-size

printf("graph_area %d,%d,%d,%d/n", xo, yo, xs, ys)

axis xlow, ylow , xhigh, yhigh

pen_color color

black, red, yellow, green, blue, cyan, magenta, dkgray, gray, ltgray, white

brush_color color

filled_rectangle x1, y1, x2, y2

dot x1, y1

line x1, y1 , x2, y2

polygon x1, y1 , x2, y2, ... xn, yn
polyline x1, y1 , x2, y2, ... xn, yn

filled_polygon x1, y1, x2, y2, ... xn, yn

filled_polygon_brush x1, y1, x2, y2, ... xn, yn

text x, y, anchor, "text"

1-----2-----3
| |
4 5 6
| |
7-----8-----9

long get_attr(string attribute);

Supported attributes are:

"draw-area-x-size"
"draw-area-y-size"
"x-scrollbar-present"
"x-scrollbar-size"
"x-scrollbar-low"
"x-scrollbar-high"
"y-scrollbar-present"
"y-scrollbar-size"
"y-scrollbar-low"
"y-scrollbar-high"
"selection-available"
"selection-start"
"selection-end"

long get_text_attr(string attribute, string text_format, ...);

Supported attributes are:

"leading"
"ascent"
"descent"
"width"

6. Argument passing.

The graph and graphm commands can be given a number of arguments. These arguments are accessible as follows.

long n_args;

The number of arguments.

arg1..argN

with N = n_args are added to the global scope and have type double * for buffers, type string for strings and type double for evaluated expressions.

Parsing the script will fail if a certain argument has not been provided. Evaluation of the script will fail if the type of the argument does not match its use.

For argument testing and argument retrieval the following functions are provided:

Numerical arguments can be retrieved by using get_double_arg(). In the graphm command, the (x, y) pairs produced by a sequence of calls to add_printf() in the graph script are accessible via global variables x and y of data type array of double.

11.6 Background Mode

Background mode is a feature for running the application under debug and CrossView Pro at the same time. This allows you to monitor the target application using CrossView Pro, while the application is running. Depending on the target hardware and/or debug instrument connected to CrossView, target execution can even be real-time.

Since CrossView's monitoring of the target hardware must be non-intrusive, not all functions of the debugger are enabled while running in background mode.

You can only use this feature if it is supported by the execution environment (see the addendum).

11.6.1 Configuration

CrossView can be instructed to automatically refresh one or more windows of the debugger periodically while running in background mode. You can use the Background Mode Setup dialog for specifying the desired set of windows to be refreshed.

Use menu item Settings | Background Mode Setup... to open the Background Mode Setup dialog.

A distinction has been made between updating the Source lines window and updating the Disassembly window. Updating the Disassembly window may be to time-consuming, so you may want to disable its updating in Background mode, while still keeping the Source lines window up-to-date when that is displayed on screen.

Use the u command to toggle the updating of windows in background mode.

FUNCTION: Toggle update of window in background mode.

COMMAND: [interval] u [d|k|r|cd|ck|cr|s|a|mem|t]

The following windows can be updated in background mode:

d (Data), k (Stack), r (Register),
s (Source), a (Assembly), mem (Memory), t (Trace)

Initially only the data window will be updated. CrossView Pro repeatedly looks at the execution environment to react on changes. It pseudo-simultaneously looks for user commands from the keyboard (or from the playback file), and periodically it updates the windows.

If all windows would be updated the update frequency would drop. That is why you can toggle a switch for each window. To toggle the updating of the register window, you can type:

If the switch for a window is 'on', it will be updated, otherwise it will be skipped.

You can also specify a new update interval.

Without arguments, CrossView Pro displays all windows updated periodically plus the update interval.

Notice that simulated I/O is done through 'invisible' breakpoints, and these must be handled inside the loop. Hence, if updating the windows takes a lot of time (many monitor commands), it will also slow down simulated I/O.

11.6.2 Manual Refresh

If you have windows which you do not want to refresh periodically, you can disable them in the Background Mode Setup dialog's refresh list, and refresh these windows manually.

Select the View | Background Mode menu item and select one of the refresh options.

Use the ubgw command.

FUNCTION: Update the appropriate window when the target runs in the background.

COMMAND: ubgw [ s | a | k | r | d | mem | t | all ]]

Section Refresh Limitation in this chapter.

11.6.3 Entering Background Mode

To run a program in background mode:

Select menu item Run | Background Mode | Run in Background.

Type the CB command on the command line.

FUNCTION: Run a program in background mode.

COMMAND: [count] CB [linenumber]

This will start the application under debug to run continuously (as with the C command), and switch CrossView Pro from Halted to Background Mode. count is assigned to the breakpoint at the current execution position as the number of times to hit this breakpoint before execution to stop. linenumber specifies the source line to place a temporary breakpoint.

The mouse pointer changes to an arrow with a small watch face underneath. This indicates that CrossView Pro is now in background mode. Some commands are treated a little different in this mode, because they can otherwise influence the running program badly. Commands that need information from the stack (like bU, bu, bb or bB) are not allowed because that information is not reliable. Other commands require great care, for example the o command.

For example if you type the g while in background mode you will see:

11.6.4 Leaving Background Mode

You can leave Background Mode in three ways:

1. Stop the target immediately:

Select menu item Run | Background Mode | Halt Target.

Enter the st command:

2. Let CrossView wait for the target to stop:

Select menu item Run | Background Mode | Wait for Target to Stop.

To wait for a breakpoint, you can use the wt command:

3. A program running in background mode also stops when it encounters a breakpoint.

FUNCTION: Stop a program in background mode.

COMMAND: st

The wt command behaves just as if you have typed the C command. CrossView Pro returns with a prompt, after the program hits a breakpoint. However, there is an interesting difference with the C command. If you push the Halt button, it returns with the background prompt. The program that runs in the execution environment continues without interruption.

FUNCTION: Wait for the running process to stop

COMMAND: wt

11.6.5 The Stack in Background Mode

While the execution environment runs in background, CrossView Pro does not allow the use of information that comes from the stack. The reason is that the running program must be stopped in order to get consistent information from the stack. Stopping (and afterwards continuing) the program conflicts with the "real-time" nature of the background mode.

If there is a need for it, you can make a macro that performs the desired operations.

11.6.6 Local and Global Variables

In background mode you can continuously monitor variables. However, realize that local variables (in CrossView Pro variables are called 'local' if they reside on the stack) cannot be monitored. Instead you will see "unknown name". Global variables have a fixed address, so CrossView Pro knows where to get their contents from.

If you are very anxious to see local variables you can first get an address and then use that address to monitor the contents. For example:

In this example sum is a long (4 bytes). You must be sure that sum remains at that address while the program is running.

The values you get this way are only valid under specific conditions. Local variables from the function main normally meet these conditions.

11.6.7 Refresh Limitation

While running the application in the background mode, the automatic refresh functionality may not be able to keep up with all the debugging information produced by the running target. Typically, the collected information will be correctly displayed and automatically updated in the current open views and no information will be lost. You might lose the debugging information when scrolling these views during the background mode. The reason is that either CrossView Pro does not run fast enough or the communication with the target hardware is not handled fast enough by the operating system.

The information that cannot be processed by CrossView Pro within the specified update interval, is displayed as either '<unknown>' or dashes. The way the lost information is displayed depends on the internal communication level within CrossView Pro where the information is lost. Information lost during communication with the target hardware is displayed as '<unknown>'. Information lost by CrossView Pro while processing and interpreting this information, is displayed as dashes.

On the next automatic or manual update, all debugging information in the currently open views is automatically updated. All visible '<unknown>' values and dashes are replaced with their actual values as produced by the running target.

11.6.8 Assertions

CrossView Pro automatically suspends assertions with the CB command.


Copyright © 2002 Altium BV