The breakpoint window manages the list of currently set breakpoints on the solution. Using the breakpoint window you can:

- enable, disable and delete existing breakpoints.
- add new breakpoints.
- show the status of existing breakpoints.
- chain breakpoints together.

Your breakpoints are stored in the session file so they will be remembered each time you work on a particular project. When running in the debugger, you can set breakpoints on assembly code addresses. These low-level breakpoints appear in the breakpoint window for the duration of the debug run but are not saved when you stop debugging.

When a breakpoint is hit then the matched breakpoint will be highlighted in the breakpoint window.

## Breakpoint states

A breakpoint can be in one of three states:

- Enabled An enabled breakpoint will stop your program running when the breakpoint condition is met.
- Disabled A disabled breakpoint will be ignored by the debugger.
- Invalid An invalid breakpoint is one where the breakpoint cannot be set, for example there is no executable code associated with the source code line where the breakpoint is set or the processor does not have enough hardware breakpoints.

## Breakpoint types

The types of breakpoint available to you is dependent upon the capabilities of the target system you are using. The most basic type of breakpoint can occur when your application is about to execute the code at a particular source line - these are termed Source Code breakpoints and are typically set using Toggle Breakpoint from the code editor.

You can also set breakpoints on the addresses and sizes resulting from evaluating a debug expression - these are termed Expression breakpoints. An expression breakpoint can be set with Set Breakpoint On on a highlighted expression using the code editor context menu. For example you can set a breakpoint on the name of function or on the name of a variable. When an Expression breakpoint is set on a function then the breakpoint will be hit when that function is executed. When an Expression breakpoint is set on a variable then the breakpoint is hit when that variable is written to.

You can change both the range of a breakpoint (the number of bytes it covers) and the trigger type of the breakpoint using the Breakpoint dialog. By changing the breakpoint type to be Ranged enables the range and trigger inputs. You can also invert the range by changing the breakpoint type to Inverse Ranged so that the breakpoint is hit when not in the specified range. So for example a breakpoint can be set when a write occurs that is not in the data region of a program.

Finally you can also specify a (masked) value that a data breakpoint will stop on and the comparison to use by changing the breakpoint type to be Valued. So for example you can set a breakpoint that will be hit when a value less than a specified number is written to a variable.

## Breakpoint actions

When a breakpoint has occurred typically you want to stop the application - this is termed a Stop action. What it means to stop the application is dependent upon the capabilities of the target you are connected to. For example some targets may stop timers when a breakpoint occurs and others may allow interrupts to be processed.

Using the Breakpoint dialog you can modify action to occur on breakpoint. If your target has trace capabilities then the Trace action specifies that the breakpoint is put into the trace. You may also be able to control starting and stopping the trace using the Trace On and Trace Off actions.

## Counted breakpoints

You can use the breakpoint dialog to associate a counter with a breakpoint - these are termed counted breakpoints. A counted breakpoint will ignore the breakpoint for the specified number of times-1 e.g. a counter value of 3 will ignore the breakpoint for 2 occurrences and on the 3rd occurrence the breakpoint will be hit. When a counted breakpoint has been hit it becomes a regular breakpoint. Note that counted breakpoints may not be available for all breakpoint types.

## Chained breakpoints

You can chain breakpoints together using the Chain Breakpoint From... dialog. When a breakpoint is chained from another breakpoint it will not be hit until the breakpoint it has been chained from has been hit. Note that when a breakpoint is chained to another breakpoint then that breakpoint will not stop your application executing it is there simply to activate the breakpoint (actually breakpoints) it is chained to.

Chained breakpoints have the breakpoint they are chained from displayed as child nodes in the tree display you can remove the chain with the right click context menu.

Note that when you delete or disable a breakpoint that other breakpoints are chained from then those breakpoints are always activated. The chain will also remain in case you wish to reset it.

## Breakpoint groups

Breakpoints are divided into Breakpoint Groups. You can use breakpoint groups to specify sets of breakpoints that are applicable to a particular project in the solution or for a particular debug scenario. Initially there is a single breakpoint group, named Default, to which all new breakpoints are added. You can add a new breakpoint group using the tool button New Breakpoint Group.

When you create a breakpoint, it is added to the active breakpoint group. You can make any group the active group by right-clicking on the group and selecting Set as Active Group.

You can enable or disable the breakpoints within a group as a whole by right clicking on the group and selecting Enable Breakpoint Group or Disable Breakpoint Group as appropriate.