WindRiver Workbench
From TracingWiki
Contents |
[edit] Wind River
[edit] Company
Wind River Systems, Inc. is a Software company providing mainly solutions for embedded systems including operating systems such as VxWorks and Wind River Linux, as well as development tools.
[edit] Kernel Tracing
Wind River Linux uses the LTTng framework as a data provider. Tracing can be activated in three different modes: normal mode, flight recorder mode and hybrid mode. In normal mode, all events are traced and written to disk during the trace period. In flight recorder mode, when the memory buffers are filled, the oldest data is overwritten. In hybrid mode, only critical, low rate, information is logged to disk such as process create/exit, while frequently occurring events are logged in a flight recorder buffer. The number and size of memory sub-buffers is user configurable. Once the LTTng trace file is generated, it is converted to System Viewer format (.wvr) so that it can be analyzed inside the Wind River Workbench.
[edit] Wind River Workbench
Wind River Workbench is an Eclipse based development suite providing a rich set of tools for software development and debugging. This document describes a few but very important features.
[edit] Target Debugging
The target can be connected with the workbench host for debugging via one of the three possible ways: A direct connection to the target with a 8250 serial connection using a null-modem cable, or via a terminal server with TCP, or by Ethernet with UDP. Once the connection is established, workbench shifts to the Device Debug perspective. Here it is possible to add breakpoints in the kernel code. Once that breakpoints is hit, the Editor inside the perspective will open the corresponding source file. On specific architectures like the IA-32, hardware breakpoints can be set. Therefore, the normal execution of the program can be interrupted when a specific variable is read or written, or when a specific instruction is read for execution. Breakpoint properties can be saved to a file and imported from it later on.
[edit] System Viewer
The Wind River Workbench System Viewer is used to capture the dynamic interactions of the operating system, device software application and target hardware. It displays graphically the trace data, allowing device software developers to detect anomalous behavior relatively quickly. The tool is architecture independent and can be used with VxWorks simulator (for VxWorks 6.x) before hardware is available and with Linux platforms using the Linux Trace Toolkit (LTTng) instrumentation. Logged events correspond to one of the following kernel activities: Semaphore gives and takes, task spawns and deletions, timer expirations, interrupts, message queue sends and receives, watchdog time activity, exceptions, signal activity, system calls, I/O activity, networking activity, memory allocation, freeing and partitioning, protection domain activity (for VxWorks 653 only).
[edit] Event Log Analysis
The System Viewer provides various graphical ways to make data analysis most effective:
- The Event Graph: The Event Graph displays the succession of events relative to each thread. Holding the mouse over any event will make the event name, time stamp and argument values appear. Icons can help identify events in the graph. Event type filters can be used to considerably reduce the amount of data to analyze.
- The Event Table: The Event Table displays events as rows of information ordered by their time stamp. The columns show the event name, the timestamp, the thread state, the event id, the time difference between current and previous event, and other different event specific arguments.
- The Memory usage graph displays memory allocation and deallocation resulting from memLib function calls. This graph shows the memory usage versus time. It also shows the addresses of memory blocks that were allocated and then freed.
[edit] Upload Modes
An upload mode consists of sending trace data from the target to the host. The choice of the upload mode depends on several factors including the amount of trace data being generated, the kind of problem being tracked down, the target buffering capacity, etc... The three types of uploads that can be selected are the Deferred Upload, the Continuous Upload and the Post-Mortem Upload.
- Deferred Upload. In the Deferred Upload (default mode), data is uploaded when the Upload command is issued from the System Viewer user interface. When using circular buffers on some systems (not VxWorks 653), the oldest data is overwritten with the newest data when the ring is full. With non-circular buffers, logging is stopped when the buffer becomes full. The limitation of this mode is that the volume of collected data depends on whatever free memory is available on the target.
- Continuous upload. Here, data is uploaded periodically from the target as buffers are filled. Tracing continues until stopped by a trigger, an API call or on demand. This method is more intrusive than the previous one and has more impact on target performance but can provide large amounts of trace data with no interruption.
- Post-Mortem Upload. This mode, also known as flight-recorder mode, is used to collect events leading up to a system failure. Events are stored in a circular ring of buffers where the oldest data is overwritten by the newest data when the ring is full. After a crash, the buffer contents can be uploaded from the System viewer user interface. This method requires that the buffer is stored in memory that is not overwritten on rebooting. This method can still be used even if the target system is not expected to crash.
[edit] Sensorpoints
Wind River Workbench diagnostics is a plugin to Wind River Workbench and provides Sensorpoints technology which can help test software relatively quickly. Sensorpoints are lines of code that can be used to instrument dynamically a running application without having to rebuild the application or reboot the device. Sensorpoints give access to global and local variables within the scope of the function to patch. They can be used to monitor, or to interfere with the execution of the application by injecting specific values in variables. Sensorpoints can also be used to create a trace of global and local variables, function calls, and to timestamp any point in the system to reveal timing problems. They can be disabled when the test is finished.
[edit] References
- http://www.windriver.com/products/device_management/sensorpoint/
- Wind River System Viewer, 3.0 – User's guide
