This chapter contains the following sections:
Transparency Mode
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
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:
From the View menu, select Command
| Emulator.
All commands entered in the Emulator Command Window are passed directly to the execution environment.
To exit transparency mode:
From the View menu,
select Command | CrossView.
In CrossView Pro, you can pass a string directly to the execution environment without leaving CrossView Pro with the o command:
o map
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.
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 (RADM: RTOS aware debugging module) 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 Pro's 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:
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:
radm: yourrtos.dll
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:
From the Tools menu, select the 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:
ce
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.
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:
From the Tools menu, select Cumulative
Profiling Setup...
Type the cproinfo command
on the command line:
cproinfo add main
To view the profiling results:
From the Tools menu, select Cumulative
Profiling Report...
Type the cproinfo command
on the command line:
cproinfo
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:
From the Tools menu, select the 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:
pe
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 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,
Syntax of CrossView eXtension Language (CXL)
,
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,
graphm "demo","show_x_t.cxl"
"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,
memget ((int []) 0x0)[$i],128,$buffer
$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,
bufa $all_data,$buffer,1024
3. Transform the buffer contents to displayable data using the graph command. For example,
graph "demo","x_t.cxl",$buffer,0,1
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.
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.
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
2. Setting the display mode:
graphm "win_title", "show_x_t.cxl" [, low_x, high_x [, low_y, high_y ] ]
graphm "win_title", "show_cross.cxl" [, low_x, high_x [, low_y, high_y ] ]
graphm "win_title", "show_plus.cxl" [, low_x, high_x [, low_y, high_y ] ]
graphm "win_title", "show_bars.cxl" [, low_x, high_x [, low_y, high_y ] ]
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 ] ]
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]
2. For displaying the generated pairs, any of the x-t plotting display scripts can be used. "show_bars.cxl" is recommended.
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]]
2. For displaying the generated pairs, the display script "show_multi_bars.cxl" is required.
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.
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.
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.
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]
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 ]
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 ] ]
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:
{ sub void p(function f) { outd(f()); outc('\n'); } sub int h() { return 1; } { //This is the "main" entry point p(h); sub int h() { return 2; } p(h); } }
This example would print the following output in the command window:
1 2
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.
CXL supports the following compound types:
Structures, unions and type definitions are not part of the CXL syntax.
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);
void printf(string format, ...);
5. GUI interaction functions available when a script is passed to the graphm command::
void printf(string format, ...);
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.
printf("graph_area %d,%d,%d,%d/n", xo, yo, xs, ys)
black, red, yellow, green, blue, cyan, magenta, dkgray, gray, ltgray, white
1-----2-----3 | | 4 5 6 | | 7-----8-----9
long get_attr(string attribute);
"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, ...);
"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;
arg1..argN
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:
long is_string_arg(long n); long is_double_arg(long n); long is_buffer_arg(long n); double get_double_arg(long n); string get_string_arg(long n); double *get_buffer_arg(long n);
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.
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 Pro, target execution can even be real-time.
Since CrossView Pro'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).
CrossView Pro 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.
From the Settings menu, select 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:
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:
xvw% u r
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.
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.
From the View menu, select Background
Mode 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.
To run a program in background mode:
From the Run menu, select 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:
xvw% g 56 Command "g" is not allowed while the emulator is running in background.
You can leave Background Mode in three ways:
1. Stop the target immediately:
From the Run menu, select Background
Mode | Halt Target
Enter the st command:
xvw% st
2. Let CrossView wait for the target to stop:
From the Run menu, select Background
Mode | Wait for Target to Stop
To wait for a breakpoint, you can use
the wt command:
xvw% wt
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
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.
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:
$adr_sum = &sum m *(adr_sum)/x4
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.
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.
CrossView Pro automatically suspends assertions with the CB command.