8.11. Preparing To Debug VxWorks 653 Integration Projects

Debugging a VxWorks 653 project uses the same Workbench interfaces and facilities, but is sufficiently different from debugging other forms of VxWorks that a dedicated discussion is appropriate.

The overall approach to debugging 653 systems consists of three steps:

  • Step 1: Build your module in debug mode.
  • Step 2: Run your system on the target.
  • Step 3: Attach the debugger to a task.

These steps are not specific to applications written in Ada. Please see the Wind River documentation, specifically the “Debug” section of the “Wind River Workbench By Example (VxWorks 653 Version)” user guide and related pages, located under “Wind River Documentation > Guides > Host Tools”. Section 6.6, “Using the Debugger” is especially applicable.

Note that Step 1 requires prior completion of the “Creating and Building a VxWorks 653 Integration Project” tutorial also provided in this GNATbench User Guide.

8.11.1. Step 1: Build your module in debug mode.

Use the “Advanced Device Development” perspective.

Complete the “Creating and Building a VxWorks 653 Integration Project” tutorial provided in the GNATbench User Guide. Upon completion you must have created and successfully built a system containing a MOS, a POS, and two application partitions, all contained within an integration project. The steps below describe how to debug any such system but are written in terms of that concrete project.

Debugging must be enabled when building a system that you wish to debug. The Ada project files in the tutorial are already set up appropriately for debugging so no changes are required.

8.11.2. Step 2: Run your system on the target.

Change to the “Device Debug” perspective.

In the Terminal view, configure the terminal communication settings so that it specifies a serial port (e.g., COM1) used to connect the target board to the host computer.

This can be accomplished via the Settings icon next to the Disconnect icon.

The default values (9600 baud, 8 bits, et cetera) likely suffice. Specify the COM port you plugged the cable into on your host machine.

The exact serial port values can be determined by examining the “target.nr” file located in the target BSP directory. Assuming the default installation directory and a wrSbc750gx board, the file would be located here:


Press OK.

Using the green Connect icon in the Terminal view, connect the terminal instance to the board.

Next, open the FTP Server application via the Wind River menu at the host operating system interface. (If you have not already done so, create the FTP user account referenced by the board startup software.)

Turn on the board (apply power). You should see boot output from the board in the connected terminal. Await complete loading of the integration project “boot.txt” file. Note that, as described below, the tutorial’s application partitions will not execute yet.

In the Remote Systems view, select the target server connection corresponding to the board. (Create the target server connection if not previously created.) Use the green Connect icon to connect the selected target server to the board.

Await completion of the connection step. Once connected to the board, the connection will appear something like the following:

With the target connection still selected in the Remove Systems view, open a host shell for that target. This can be accomplished using the “->i” icon in the icon bar at the top of Workbench itself. (You can also use the Target menu to open a host shell.)

You should then see output in the shell, with the name of the MOS project as the prompt (“[coreOS] ->” in this tutorial).

You are now ready to either run or debug the tutorial system. Initially, the tutorial application partitions do not execute because the active schedule does not allocate any time to them. This is by design, so that you can set up debugging if desired. See the text in the Concluding Points at the end of this document for details of setting up such a schedule.

If you simply want to run the system instead of debugging it, enter “arincSchedSet 1” (without the quotes) at the host shell prompt. This will apply a different schedule that allocates time to the application partitions. Output will then appear in the connected terminal instance in the Terminal view.

Alternatively, if you want to debug the system, follow the steps below before changing the schedule in the host shell.

8.11.3. Step 3: Attach the debugger to a task.

We will debug the receiver partition that acquires and displays integer values from the sender partition.

These steps correspond to the subsection “Attaching the Debugger to a Partition Task” in the Wind River document cited earlier.

In the Remote Systems view, select the connection for your target and expand the target connection “protection domains” section so that you can see the “receiver,” “sender,” and “vxSyslib” partitions. Expand the “receiver” partition. Under that partition, expand the “Protection domain tasks” section. You will see a single task there, named “tReceiver,” in the suspended state.

Right-click on the “tReceiver” task and choose the “Debug -> Attach to tReceiver” menu entry.

Doing so will create a new “Attach Target Context” debug launch configuration for the “tReceiver” task, automatically, the first time you debug the system. In subsequent debugging sessions, however, the Launch Configuration Selection dialog will be displayed, in case you want to change it. Assuming the launch configuration is still correct, simply ensure “Update and launch the selected launch configuration” is selected and press OK.

In the Debug view you will see the new Attach Target Context showing the suspended “tReceiver” task.

Using the Project Explorer view, expand the “receiver” project (nested within the Integration project), to show the “src” folder. Expand that folder and open the “tf_receiver.adb” file. This file contains the package body that declares the “Receiver_Process” task body.

Set a breakpoint on an arbitrary line or lines in the task body. For example, set a breakpoint on the line that prints the values (the call to Put on line 59, or thereabouts). You can also set breakpoints on those parts of the task body elaboration that involve actual execution, such as the declaration of the constant Maximum_Debug_Strength_Length (line 17).

In the host shell, enter “arincSchedSet 1” (without the quotes) at the prompt to enable application partition execution. The earliest breakpoint set in the task will be hit and the host shell will reflect the breakpoint being reached.

The editor containing the source will show the line at which the debugger has suspended, due to the breakpoint being hit.

The Debug view will show the receiver task suspended at the breakpoint.

You can use the debugger as usual, for example to step, view values of variables, and so on.

If we disable the breakpoints and let the application partitions execute, we see the expected output in the terminal.

8.11.4. Concluding Points

You should have a partition schedule set up beforehand, so that those application partitions to be debugged do not start executing the moment the system image is downloaded to the target. Schedules are defined in the “module.xml” file. In the tutorial this file appears as follows:

For a discussion of setting up schedules, see section 5.8.2 “VxWorks 653 Application Projects” in the “Wind River Workbench By Example (VxWorks 653 Version)” user guide, located under “Wind River Documentation > Guides > Build > VxWorks 653 Partition OS Projects”.