Breakpoint types
Depending on the C-SPY driver you are using, C-SPY supports different types of breakpoints.
Code breakpoints
Code breakpoints are used for code locations to investigate whether your program logic is correct or to get trace printouts. Code breakpoints are triggered when an instruction is fetched from the specified location. If you have set the breakpoint on a specific machine instruction, the breakpoint will be triggered and the execution will stop, before the instruction is executed.
If you are using the C-SPY OCD driver, code breakpoints (implemented as software breakpoints) are only available when a device based on the S2 or S3 core has been selected. When a device based on the S1 core has been selected, you must instead use Code hardware breakpoints.
Code hardware breakpoints
Code hardware breakpoints are triggered when an instruction is fetched from the specified location. If you have set the breakpoint on a specific machine instruction, the breakpoint will be triggered and the execution will stop.
For emulators supporting Fetch break before execution, the breakpoint type Code hardware is implemented as an event fetch breakpoint.
For the OCD emulators, the breakpoint type Code hardware is implemented as a break after execution hardware event. See the description under Event breakpoints.
Event breakpoints
The hardware debugger systems can define one or more hardware events, such as various types of fetch conditions and various data access conditions, and sequences of events. You can make use of these events by setting Event breakpoints. You can make these event breakpoints to be either code or data breakpoints.
For the OCD emulators, fetch condition hardware events are of the type break after execution. When a hardware event is used as a code breakpoint, execution always slips a number of cycles from the address the breakpoint has been set on. This slip occurs also when you use debug commands like Step Over, Run to cursor, etc. Because of this, terminal I/O is not supported and the application will not stop at the exit label. To be able to use all available events (normally two) as breakpoints, you must also deselect the Stack options in the IDE Options dialog box.
Log breakpoints
Log breakpoints provide a convenient way to add trace printouts without having to add any code to your application source code. Log breakpoints are triggered when an instruction is fetched from the specified location. If you have set the breakpoint on a specific machine instruction, the breakpoint will be triggered and the execution will temporarily stop and print the specified message in the C-SPY Debug Log window.
Trace Start/Stop Trigger breakpoints
Trace Start Trigger and Trace Stop Trigger breakpoints start and stop trace data collection—a convenient way to analyze instructions between two execution points.
Data breakpoints
Data breakpoints are primarily useful for variables that have a fixed address in memory. If you set a breakpoint on an accessible local variable, the breakpoint is set on the corresponding memory location. The validity of this location is only guaranteed for small parts of the code. Data breakpoints are triggered when data is accessed at the specified location.
The execution will usually stop directly after the instruction that accessed the data has been executed.
Data Log breakpoints
Data log breakpoints are triggered when a specified variable is accessed. A log entry is written in the Data Log window for each access. Data logs can also be displayed on the Data Log graph in the Timeline window, if that window is enabled.
You can set data log breakpoints using the Breakpoints window, the Memory window, and the editor window.
Using a single instruction, the microcontroller can only access values that are two bytes or less. If you specify a data log breakpoint on a memory location that cannot be accessed by one instruction, for example a double or a too large area in the Memory window, the result might not be what you intended.
Immediate breakpoints
The C-SPY simulator lets you set immediate breakpoints, which will halt instruction execution only temporarily. This allows a C-SPY macro function to be called when the simulated processor is about to read data from a location or immediately after it has written data. Instruction execution will resume after the action.
This type of breakpoint is useful for simulating memory-mapped devices of various kinds (for instance serial ports and timers). When the simulated processor reads from a memory-mapped location, a C-SPY macro function can intervene and supply appropriate data. Conversely, when the simulated processor writes to a memory-mapped location, a C-SPY macro function can act on the value that was written.