|
|
|
|
Debug Breaks and Breakpoints
In order to pause the program execution at any given point, the NBC Debugger for NXT provides 2 solutions:
- Hard coded debug breaks
- Soft breakpoints
Debug Breaks
Debug breaks are hard coded in the NBC source code. The simplest debug break syntax is:
This line will cause the program to pause execution and "break into" the debugger at the instruction
immediately after this line.
There are 2 more complex debug breaks that are handled by the debugger.
Conditional hard coded debug breaks pause the program execution if a simple logical expression added to the
debug break evaluates to true. The conditional debug break syntax is:
#pragma debugbreak if EXPRESSION
The logical expression (EXPRESSION above) has a left side variable or constant value, an operator
and a right side variable or constant value. For example the following are valid conditional
debug break lines:
#pragma debugbreak if x == 3
#pragma debugbreak if foo <= goo
#pragma debugbreak if a<5
#pragma debugbreak if myinteger != 10
#pragma debugbreak if mystring == 'hello'
#pragma debugbreak if 'stop' == mystring
Valid logical operators are:
- == [equals]
- = [equals]
- != [not equals]
- <> [not equals]
- < [less than]
- > [greater than]
- <= [less than or equals]
- =< [less than or equals]
- => [greater than or equals]
- >= [greater than or equals]
As shown above, the left and right operators are interchangeable. There can be any (including 0)
number of space characters between the left, right values and the logical operator.
Counter-type hard coded debug breaks pause the program execution if the program execution has passed over
the debug break a specified times or more. The counter-type debug break syntax is:
#pragma debugbreak count CONSTANT_NUMBER [reset]
The CONSTANT_NUMBER expression can be any unsigned long number (0...4294967295). If the number is 0,
the program execution will pause every time on the debug break (it is practically an unconditional debug break).
If the expression cannot be evaluated as a number, it will be substituted with a 0.
If the keyword "reset" is added to the end of the debug break line, the hit counter will be set to 0 every time the
program execution pauses at the debug break. For example:
#pragma debugbreak count 5
#pragma debugbreak count 8 reset
The current hit count for every hard coded debug break is visible in the breakpoints window and can
be reset to 0 by clicking at the "Reset the Hit Counter" tool in the breakpoints toolbar.
When a hard coded debug break line is visible in the source code window and it's enabled, it's marked with a blue dot:
When a hard coded debug break line is visible in the source code window and it's disabled, it's marked with a blue circle:
Debug breaks do not implement any functionality on the device, which means the following will apply:
- Cannot "Run to" a debug break line. If you select a debug break line in the source code window and try to use the "Run to Instruction" command on it,
the execution will stop on the next line after the debug break line
- Cannot place a soft breakpoint on a debug break line
- Cannot step in or over a debug break line. During step-by-step execution the program counter will jump from the instruction before the debug break straight to the next instruction after the debug break.
Breakpoints
Breakpoints can be added and removed at any time (even while the program is running) within the debugger.
In order to do so, you need to move the cursor to the line in the source code window, where a soft breakpoint
is needed, and then use the source code window's context menu (activated by a right click on the given line), or
with the breakpoint flyout toolbar (clicking on the breakpoints tool in the Source toolbar:
Enabling/disabling a breakpoint can be done with the breakpoint window's enable/disable tools
as well as the source code window's enable/disable breakpoint tools.
When a breakpoint line is visible in the source code window and it's enabled, it's marked with a yellow dot:
When a breakpoint line is visible in the source code window and it's disabled, it's marked with a yellow circle:
For performance reasons the debugger sets the number of maximum enabled breakpoints within a subroutine
or thread to 1. When you try to add or enable a second breakpoint within the subroutine or thread, the
debugger will ask you to decide which one of the breakpoints needs to be enabled.
Breakpoint Window
The breakpoint window will list all the hard coded debug breaks and soft breakpoints in the currently loaded project.
Enabling/disabling a debug break or a breakpoint can be done with the breakpoint window's enable/disable tools
as well as the source code window's enable/disable breakpoint tools. Hard coded breakpoints cannot be completely removed
from within the debugger, only by deleting the line from the source code and recompiling.
When you select a line in the source code window that has a hard coded debug break or a breakpoint
added to it, the breakpoint window will show the selected breakpoint highlighted. If you want to
enable or disable that debug break or breakpoint, you can simply toggle the checkbox that belongs to
the highlighted line in the breakpoint window.
If you want to find a debug break or breakpoint in the source code, you can use the "Show Breakpoint Location" tool
in the Breakpoints toolbar, or just by simply double clicking on a line of the breakpoint window.
A known functionality shortcoming with the current breakpoint implementation is, that the debugger
does not keep a persistent list of soft breakpoints through re-loading programs from BricxCC.
This is an unfortunate side effect because the source editor (BricxCC) and the debugger are separate
code base and the debugger is not aware of the changes that went into the source code between
program re-loads.
It would be possible to add some heuristics to match the previous and current source code line by
line, and find the exact same lines in the new code where breakpoints had been applied before
editing. This functionality however does not greatly effect the over all debugging functionality
hence currently it has a rather low priority.
|
|
|
