Use the following procedures to start debugging your Verix application.
Automatic Startup Use the following procedure for debugging a Verix application.
1 Download the application and the debug monitor (dbmon.out).
Both require signature files (*.p7s) for authentication.
a Terminal debug communication parameters are determined by *DBMON. If not set, dbmon uses terminal COM1 at 115.2 baud. Otherwise the format of the *DBMON value is pb where, p is the port (0=USB, 1=COM1,
2=COM2), and b is the baud rate. See <svc.h> for values. (For USB, this is ignored).
Note that the baud rate must be compatible with the VRXDB tgt.baud property.
b Set *GO to run dbmon.
c Restart the terminal.
When dbmon starts it beeps twice.
2 Locate the directory containing the .axf file for the application and run VRXDB using a command such as:
vrxdb test42.out
After issuing the vrxdb command, the debugger starts and usually displays the code for main() (but sometimes src tab needs to be clicked). RVD does not automatically run target program to main(). You must execute two “step over”
commands to get through the C library startup code and the main()’s function entry code, or set a breakpoint and go.
If the .axf file is not in the current directory, execute VRXDB with a command such as:
vrxdb test42.out \myapps\test42.axf
TIP Store the dbmon in flash so that it does not have to be downloaded every time the application is updated.
DEBUGGING
Debugging Procedures
To do any special setup before starting the debugger (for example, changing the baud rate), do not specify a target program when running VRXDB. Enter any required commands at the VRXDB prompt. When you are ready begin debugging, enter a debug command, for example
debug test42
If debugging the same program repeatedly, create an initialization file that
contains the setup and debug commands. Also, create a Windows shortcut so as to do this by double-clicking a desktop icon.
Manual Startup Debug sessions can be started from the debugger if no target program is specified on the VRXDB command line or the debug command. The following procedure is required for the following special cases:
1 launch the debugger using a debug command with no arguments, if the debugger is not already running.
2 Select a program to debug using the RVD Connection Control box.
If it does not pop up automatically, look for a link labeled “Click to Connect to a Target” or select File>Connection>Connect To Target.
Under the “Verix-Applications” entry, there is a list of .out files on the
terminal. Click the check box for the desired target program. This starts a task running on the terminal and connects the debugger to it. At this point you can examine its memory and registers, step instructions, and so on.
3 Locate the .axf file.
To get a source-level view of the program, you must specify where to find its debug information in RVD. This is the .axf file generated when you linked the application. If the main window displays a link labeled “Click to Load Image to Target,” click it. If not, select File>Load Image from the RVD menu to display the Load File to Target dialog.
a Check the Symbols Only box.
If the Symbols Only box is not checked, the debugger attempts to download the code to the terminal.
CAUTION Do not click a link labeled “Click to Load xxx.axf.”
Although RVD remembers the last file, it does not remember the Symbols Only option that must accompany it. Always use the load image dialog box.
DEBUGGING
Debugging Procedures
Ending a Debug Session
To end a debug session, uncheck its entry in the RVD Connection Control box.
The target task is terminated if it is still running. If you prefer to leave the task running, select File >Connection>Disconnect (Defining Mode) and select Free Running.
When finished debugging, close RVD and use the quit command to exit VRXDB.
Do any of the following to start another debug session:
• Leave RVD running and use the Manual Startup procedure.
• Close RVD, then use another debug command to restart it.
• Close everything and start over.
Normally you do not have to restart dbmon, but it is a good idea to reset the terminal occasionally to clear old tasks.
Debugging in Different Groups
VRXDB recognizes when a target program is in a different group and directs dbmon to switch groups as necessary. dbmon should always run from GID1. This facilitates program development, even if the application will run in a different group.
Debugging an Existing Task
If the target program specified in a debug command or selected in the Connection Control box corresponds to an already running task, the debugger takes control of it instead of starting a new task. The task is stopped at its current point of
execution.
If you attach to an existing task using the Connection Control box, one change to the Manual Startup is necessary:
• You must uncheck the Auto-Set PC and Set PC to Entry Point options in the Load File to Target dialog.
Otherwise the debugger forces the execution address back to the start of the task.
Using VRXDB Without the Debugger
The Verix utility commands can be useful independent of the debugger. Simply connect to the target and enter VRXDB commands to list files, and so on. Use the -n and –x options to run VRXDB commands in a single step. For example,
vrxdb -n -x “dir F:”
lists the Verix flash files and returns (dbmon must be running on the terminal).
Multitask Debugging
When running multiple tasks under debug control, the following are important considerations:
• RVD thinks that each Verix target task under debug control is running on a separate CPU. So, for each task under debugger control, an RVD connection must be established and the corresponding Target Debug Info (.axf file) must be loaded. When a RVD connection is established, the corresponding task starts on the target terminal. If the task is already running under debug control, the RVD connection does not start another instance of the task.
DEBUGGING
Debugging Procedures
• Currently, only 1 task under debug control can be active at any time. Other tasks under debug control must be stopped.
• VRXDB commands that require communication to the target terminal cannot be entered when a task under debug control is active.
The following are rules to determine if a task is under debug control
• If the debug monitor in the terminal, dbmon, starts the task, it is under debug control. dbmon starts a task if RVD attempts to establish a connection. This can be the result of any of the following:
• Starting VRXDB with a debug target task parameter. For example, vrxdb mytest.out.
• Entering the VRXDB debug command.
• Opening the File/Connections dialog in RVD and checking the task name.
In each case, dbmon starts the task unless it is already running under debug control.
• A task started by a task under debug control, is also under debug control. This behavior is controlled by the VRXDB dbg.tasks property. By default, tasks created by tasks being debugged are under debug control. To change this behavior, set the property to “none” before the new task starts.
• A task can be attached to the debugger using the VRXDB attach command.
Currently, this command can only be used on a task with a defined RVD connection that was previously freed.
Multitask Debugging Procedure
For a multi-tasking scenario, take an example of a parent task, P, which starts a child task, C. Use the following steps to debug these tasks.
1 Start the debugger on the parent task.
Methods to start the debugger on a task are:
The debugger can be started using either the manual or automatic startup procedures described in the previous sections.
2 Debug the parent task as necessary.
When the parent task runs the child task, the child task stops on its first instruction.
To debug the child task:
a Stop the parent task some point after it runs the child task.
b Manually establish a connection to the child task by using the following steps:
• Select the File/Connection/Connect To Target option from RVD and
DEBUGGING
Debugging Procedures
• Load the symbol information (c.axf) from the RVD File/Load Image dialog. Ensure that the Symbols Only box is checked.
The child task displays in the RVD source window (the current tab may be at dsm instead of src).
At this point, the child task is at its first instruction. To get to the C code, press the high-level step several times or set a break point and run. Debug the child task as necessary.
3 Switch tasks.
RVD and VRXDB allow selection of a different debug task/connection anytime the current task/connection is stopped. To switch tasks, use the “Change to Next Active Connection” button on the RVD toolbar (the plus + sign with a drop down arrow next to it).
VRXDB free and attach Commands Example
Though the preceding procedure works, it may be cumbersome for debugging some multiple task scenarios. For example, there may be a server and client task and the server processing for a specific client request needs to be debugged. But that client request may only occur after the server has processed various other client requests. To debug this type of situation, use the VRXDB free and attach commands.
Use a procedure similar to the steps in Multitask Debugging Procedure to establish debug control for both the server and client tasks.
While the server task is stopped, temporarily free it from debug control by entering the VRXDB free command at the VRXDB command prompt. free requires the task ID. To determine the task number for the server task, use the VRXDB tasks command. Once the free command is entered, the server task is normally scheduled.
Prior to the client sending the server request that needs debugging, stop the client task. At the VRXDB command line, use the attach command to put the server task back under debugger control. When the attach command is entered, the task stops and is under debugger control.
Use the RVD “Change to Next Active Connection” button as necessary to switch between tasks and debug.
Ideally, it would be preferable to be able to set breakpoints in both tasks and then just start both of them running. But due to limitations in the current RVD and VRXDB versions, this is not supported. The VRXDB attach and free commands provide a workaround to allow debugging of multiple tasks.
DEBUGGING
Tips, Pitfalls, and Annoyances
*DBMON Abort Codes
Table 9 lists common debug abort codes.