From the Products tab on Wind River’s web site, select Download Center. Then select Software. Listed among the top three evaluations is Workbench 3.0 for On-Chip Debugging. Click that link, then click Download, and you’re given the choice of downloading or getting a CD. Clicking Download here takes you to an information form to fill out. After completing the form you’ll be able to download the 600 MB file.
Wind River uses the FlexLM license manager. The evaluation comes with a 30-day license.
9.4.2 Getting Started
When you start this version of Workbench, after getting past the workspace selection and Welcome screen, you’re presented with a start dialog that offers choices such as creating or editing a launch configuration, connecting, or syncing with a target. The main editor window shows a list of Getting Started Resources (Figure 9.16) with links to documentation and other support resources. Workbench supports an RSS Feeds view that is already subscribed to several Wind River feeds. Roll the cursor over an item in the Feeds view and a pop-up appears, displaying a summary of that item.
Figure 9.16: Workbench initial screen.
The default perspective is called Application Development. It’s similar to the C/C++ perspective with the addition of several views, including:
• Remote Systems
• File Navigator
• Kernel Objects
• Feeds
• Build Console
Workbench makes a distinction between consoles that are attached to targets and the local console that displays the build results. The latter is called the Build Console.
There are some additional items in the tool bar. There’s a feature to make the editor emulate vi. Another feature turns on Emacs key bindings, replacing some of the standard Eclipse key bindings.
9.4.3 On-Chip Debugging
The objective of the OCD version of Workbench is to provide tools that help in the early stages of a project, such as bringing up a new board. At this point there’s no operating system, so OCD supports a stand-alone application environment where the executable image is expected to be self-contained. We also can’t expect the hardware itself to be working, so usually a hardware debugging device such as a JTAG probe or an in-circuit emulator (ICE) is called for.
Accordingly, Workbench OCD provides Remote System connections for two classes of hardware debugging products, Wind River ICE and Wind River Probe. Both products use either JTAG or BDM ports to connect to a target board. Probe connects to the host through USB, while ICE connects via Ethernet and an RS-232 port. Both devices support typical debugging features, such as:
• Execution controclass="underline" download, start, stop
• Breakpoints
• Examine and modify memory and registers
• Flash programming
• Hardware Diagnostics
Additionally, the ICE class products offer profile analysis and trace capabilities.
Wind River provides a number of sample programs to illustrate various features of Workbench. Under File→New is an Example… menu item that can be used to create various sample projects. One class of examples is that of stand-alone projects that require no OS support (Figure 9.17). The C Demonstration program is a good starting point.
Figure 9.17: Sample project selection.
In place of an actual ICE or Probe device, the evaluation version provides an instruction set simulator for a PowerPC MPC8260 processor. You establish a connection to the instruction set simulator in the same way you would to any other type of remote system (see Figure 9.18).
Figure 9.18: Remote system connection.
Next, you create a launch configuration for the project that uses the ISS connection. The dialog for setting up an OCD launch configuration is somewhat different from the launch configurations we’ve seen before (Figure 9.19). Perhaps not surprisingly, the dialog deals with a lot of hardware issues. The Download tab lets you specify the files that will be downloaded to the target.
Figure 9.19: OCD launch configuration.
Clicking Debug brings up the Device Debug perspective, which is similar to the standard Debug perspective, with some additional views (Figure 9.20). A System Context view appears in the editor window. This is a mixed C and assembly language listing of the code being executed. The Debug Symbol Browser shows all of the symbols in the project and supports operations such as going directly to the symbol’s declaration and setting a breakpoint at the symbol.
Figure 9.20: Device Debug perspective.
From this point on, debugging is essentially the same as we’ve seen earlier. Workbench OCD supports some additional views that are only meaningful if the debugging tool provides the necessary data. These include:
• Flash Programmer
• Hardware Diagnostics
• OCD Statistical Code Profiling
• Trace
9.4.4 Analysis Tools
The full Workbench product includes several analysis and visualization tools similar to what we’ve encountered with the other products reviewed in this chapter. They aren’t included with the Workbench OCD evaluation.
All but one of these tools (System Viewer) were previously offered as an add-on product called Scope Tools for Test and Validation. These are now included in the base Workbench platform. Each of these tools has its own Eclipse perspective with views appropriate to the task at hand.
This is the Wind River equivalent of the Linux Trace Toolkit. It was previously called WindView and has been around for quite some time[14]. Like LTT it provides a graphical visualization of system events to reveal the complex interactions of tasks, threads, and interrupts (Figure 9.21). I think of this kind of tool as a logic analyzer for the software.
Figure 9.21: System Viewer.
You can scroll around the trace and zoom in on particular areas to see more detail. The set of processes, threads, and events being traced can be filtered to focus attention on specific areas of concern.
This is a dynamic performance profiler that shows where a program is spending its time. An agent on the target periodically takes a “snapshot” of the currently executing process and its call stack. These snapshots are saved in a buffer and periodically uploaded to the Profiler GUI on the host.
The Profiler graphically reports the percentage of CPU time spent in any function (Figure 9.22). This view organizes the information in a call stack format. Current Direct % is the time spent in the function itself. Current Indirect % is the time spent in the function and all functions that it calls. Click on a function name in the Performance Profiler, and an editor opens at that function.
Figure 9.22: Performance Profiler.
This tool serves as a memory leak detector much like MontaVista’s implementation of mpatrol. On the target it dynamically patches the memory allocation functions with instrumentation code. This approach means the application doesn’t have to be rebuilt for memory analysis and also means you can analyze any code, not just your own.