Echelon IzoT NodeBuilder - Manual (Page 252)

Halting an Application
You can stop an application while it is running in debug mode by clicking the halt button ( ) on the
Debugger toolbar. Alternatively, you can click Debug, point to Halt, and select Current Device or
All Devices. If the device halts in application code, the editing pane displays the line of code where
the application was halted using an arrow (
) in the left margin. If the device halts in system code, no
arrow will appear and a “Call stack not available” message appears in the Call Stack pane.
To resume execution of an application that has halted, click the resume button ( ) on the Debugger
toolbar, click Debug and then click Go, or press F5. The application will continue running until it hits
another breakpoint (or the same one again). You can also move your cursor and click the run to cursor
button to have the application resume execution until it gets to the line containing the cursor.
Running to the Cursor
You can make an application run to a cursor location. To do this, place the cursor in the line where the
application is to be halted, and then either click the run to cursor button (
) on the Debugger toolbar
or click Debug and then click Run to Cursor. The application will automatically halt when it reaches
the cursor. If you move the cursor, you will need to set this option again to re-enable this behavior.
Note that Run to cursor breakpoints will be cleared after the first time that they are encountered.
Setting and Using Breakpoints
You can use breakpoints to set lines in your source code where the application will stop running so you
can check variable values, device hardware status, and so on. This lets you identify the line of code
causing an error or unexpected behavior.
To set a breakpoint, place your cursor in the line of code in which you want to set a breakpoint and
click the Toggle Breakpoint button (
) on the Debugger toolbar. Alternatively, you can either
right-click the line of code and select Toggle Breakpoint on the shortcut menu; click Debug, point to
Breakpoints, and then click Toggle Current Line; or press F9. When you set a breakpoint, the
breakpoint icon (
) appears to the left of the line of code.
You can only set breakpoints on lines that contain underlying executable code. Examples of such lines
include function calls, variable assignments, if statements, and macros. Examples of source lines that
you cannot set breakpoints on include comments, when() clauses, pre-processor directives, and
variable declarations.
When the application reaches a line with a breakpoint, the application halts and an arrow icon appears
on top of the breakpoint icon (
) to the left of the line of code.
Notes:
• For 5000 or 6000 Series chips, you cannot set breakpoints in interrupt-tasks or set breakpoints in
functions that are called from interrupt-tasks. If you set a breakpoint in an interrupt-tasks or in a
function called from an interrupt-task and interrupts are enabled [with the interrupt_control()
function], the debug target will report a system error, reset, and then go into the soft-offline state.
If you re-enable interrupts in the reset clause before the device can go offline, the NodeBuilder
debugger might lose communication with the device and therefore need to set the device
applicationless
• Do not edit source files when running an application in debug mode because the source code will
no longer reflect the active image in the debugger, and breakpoints may lose synchronization. If
you believe breakpoints have lost synchronization, you can stop the debugging session, recompile
and load the device application, and then restart the debugging session.
• If you place a breakpoint in a reset() clause and perform a software reset, you may have to force
the application to continue using the resume ( ) button for it to reach your breakpoint.
238 Using the NodeBuilder Debugger