Our sample application, which we have just compiled and linked, is now built and ready to run. In this section we'll concentrate on downloading and debugging this application, and using the features of CrossStudio to see how it performs.

###### Getting set up

Before running your application, you need to select the target to run it on. The Targets window lists each target interface that is defined, as does the Targets menu, and you use these to connect CrossStudio to a target. For this tutorial, you'll be debugging on the simulator, not hardware, to simplify matters. To connect to the simulator, do one of the following:

- From the Target menu, click MAXQ Simulator.

—or—

- From the View menu, click Targets to focus the Targets window.
- In the Targets window, double click MAXQ Simulator.

After connecting, the connected target is shown in the status bar:

The color of the LED in the Target Status panel changes according to what CrossStudio and the target are doing:

- White — No target is connected.
- Yellow — Target is connected.
- Solid green — Target is free running, not under control of CrossStudio or the debugger.
- Flashing green — Target is running under control of the debugger.
- Solid red — Target is stopped at a breakpoint or because execution is paused.
- Flashing red — CrossStudio is programming the application into the target.

Because the core simulator target can accurately count the cycles spent executing your application, the status bar shows the cycle counter panel. If you connect a target that cannot provide performance information, the cycle counter panel is hidden. Double clicking the Target Status panel will show the Targets window and double clicking the Cycle Counter panel will reset the cycle counter to zero.

###### Setting a breakpoint

CrossStudio will run a program until it hits a breakpoint. We'll place a breakpoint on the call to `debug_printf` in main.c. To set the breakpoint, Move the cursor to the line containing `debug_printf` and do one of the following:

- On the Build tool bar, click the Toggle Breakpoint button.

—or—

- Type F9.

Alternatively, you can set a breakpoint without moving the cursor by clicking in the gutter of the line to set the breakpoint on.

The gutter displays an icon on lines where the breakpoints are set. The Breakpoints window updates to show where each breakpoint is set and whether it's set, disabled, or invalid—you can find more detailed information in the Breakpoints window section. The breakpoints that you set are stored in the session file associated with the project which means that your breakpoints are remembers if you exit and re-run CrossStudio.

###### Starting the application

You can now start the program in one of these ways:

- From the Debug menu, click Start Debugging.

—or—

- On the Build tool bar, click the Start Debugging button.

—or—

- Type F5.

The workspace will change from the standard Editing workspace to the Debugging workspace. You can choose which windows to display in both these workspaces and manage them independently. CrossStudio loads the active project into the target and places the breakpoints that you have set. During loading, the the Target Log in the Output Window shows its progress and any problems:

The program stops at our breakpoint and a yellow arrow indicates where the program is paused.

You can step over a statement by selecting Debug > Step Over, by typing F10 or by clicking the Step Over button on the Debug tool bar. Right now, we'll step into the next function, `factorial`, and trace its execution. To step into `factorial`, select Debug > Step Into, type F11, or click the Step Into button on the Debug tool bar. Now the display changes to show that you have entered `factorial` and execution is paused there.

You can also step to a specific statement using Debug > Run To Cursor. To restart your application to run to the next breakpoint use Debug > Go.

Note that when single stepping you may step into a function that the debugger cannot locate source code for. In this case the debugger will display the instructions of the application, you can step out to get back to source code or continue to debug at the instruction code level. There are may be cases in which the debugger cannot display the instructions, in these cases you will informed of this with a dialog and you should step out.

###### Inspecting data

Being able to control execution isn't very helpful if you can't look at the values of variables, registers, and peripherals. Hovering the mouse pointer over a variable will show its value as a data tip:

You can configure CrossStudio to display data tips in a variety of formats at the same time using the Environment Options dialog.

The Call Stack window shows the function calls that have been made but have not yet finished, i.e. the active set of functions. To display the Call Window, select Debug > Debug Windows > Call Stack, or type Ctrl+Alt+S.

You can find out about the call stack window in the Call stack window section.

###### Program output

The tutorial application uses the function `debug_printf` to output a string to the Debug Console in the Output Window. The Debug Console appears automatically whenever something is written to it—pressing F5 to continue program execution and you will notice that the Debug Console appears. In fact, the program runs forever, writing the same messages over and over again. To pause the program, select Debug > Break or type Ctrl+. (control-period).

In the next section we'll cover low-level debugging at the machine level.