WindView 2.0
6.1 Introduction
Configuring WindView
Events
®
6-2
What is WindView?

A software ‘logic analyzer’ or ‘run-time analyzer’ for your
multitasking application.

A high precision graphical view of events, tasks, and
interrupts in your application, shown across time.

Helps diagnose race conditions and timing problems.

Data logging can be triggered to focus on events of
interest.

Other programs may access your event log using C++ or
Tcl programmatic interfaces to the event base.

WindView for VxSim Lite comes with Tornado. For other
targets, WindView is an optional product.
®
6-3
Host/Target Architecture
Host
Target
VxWorks and
Application
File
Events
WindView
Graph
evtRecv
tWvUpload
Event
Buffer
tWvRBufMgr
®
6-4
Configuring WindView

Configuring WindView involves answering several
questions:
– When does event logging start and stop?
– Which events are logged?
– How is the event buffer managed?
– When are event data uploaded to the host?
– How are event data uploaded to the host?
– What destination will receive the event data?

Providing the answers to these questions may involve:
– Configuring VxWorks and the target server
– Using the WindView and Triggering host tools
– Calling target routines to control logging and upload
®
6-5
Target Server File System (TSFS)

Extends the virtual I/O facilities provided by the target
server and WDB agent:
– Provides remote access to host filesystem.
– Target server can also open TCP socket connections on the host
on behalf of target.
Both methods are available for event log upload.

The user must configure the target server to enable TSFS.
– Specify file system root directory.
– Specify read or read/write access. Write access is required for
the TSFS event log upload to a file.

TSFS component of the WDB agent must be included.
®
6-6
Your Application VS. tWVUpload

Uploading intrudes on the running of your application, as
does buffer management.

Use triggering to start WindView, focusing on the area of
code you are interested in; use deferred upload mode so
that the upload occurs after the relevant portion of the
code is done and event data are gathered.

Use post-mortem mode if you expect a crash and want to
see what is happening just prior to the error.

Stop dynamic buffer management by defining the
minimum and maximum number of buffers to be the
same.
®
6-7
WindView 2.0
Introduction
6.2 Configuring WindView
Events
®
6-8
Configuring VxWorks for WindView
®
6-9
Which Events are Logged?

There are three nested classes or levels of events which
may be be logged:
– Context switch events
– Task state transition events
– Additional instrumented events
Each class includes the preceeding classes.

At the Additional Instrumentation level, one may select
which among several instrumented VxWorks Libraries
will log events.

Programmatically, one may also
– Instrument particular objects.
– Log user events with wvEvent().
®
6-10
WindView Collection Configuration
®
6-11
Upload Paths and Destinations

WindView defines several upload paths

Except for the Direct to Graph path, one must specify
additional information on the upload destination:
– host and port number for socket upload paths.
– directory and file name for file upload paths.
®
6-12
Upload Mode

Deferred upload:
– Data are uploaded on request after logging stopped
– Logging also stops if event buffer becomes full.

Continuous upload:
– Data are uploaded periodically as logging continues.
– Ring buffer grows during times of greater event production,
shrinks once data are uploaded.
– Logging stops if event buffer becomes full.

Post mortem upload:
– Data are uploaded on request after logging stops, often after
warm reboot.
– Event buffer is treated as circular. Buffers must be in memory not
overwritten during the reboot.
®
6-13
Setting Upload Path and Mode
®
6-14
Starting and Stopping Collection

Several methods:
–
and
buttons on WindView control panel.
– Triggering facility.
– Programmatic control from target.

For socket upload paths, start evtRecv or open listening
WindView graph before uploading.
– For continuous mode, start the listener before starting collection.

For information about programmatic control, see:
– wvLib reference page.
– usrWindview documentation in WindView User’s Guide.
®
6-15
Triggering

Associates actions with WindView events.
Action may be:
– Start or stop WindView logging.
– Call a function.
– Optionally, disable trigger and/or enable another.

Trigger fires when enabled and event matches criteria:
– Any combination of event type, context, and involved system
object ID.
– Optional conditional expression involving integral global variable
or ISR-safe function of no argument.

User trigger events, distinct from user WindView events,
may be generated using trgEvent().
®
6-16
Triggering User Interface
®
6-17
WindView 2.0
Introduction
Configuring WindView
6.3 Events
®
6-18
Data Collection is based on Events

What is an Event?
“...an event is any action undertaken by a task or an ISR that can
affect the state of the real-time system.”
– System library instrumentation points.
– User events.

Examples:
– Task state change.
– semGive & semTake.
– msgQSend and msgQReceive.
– Timer expiration.
– Anything you define as an event.
®
6-19
User-Defined Events
STATUS wvEvent (eventNo, buffer, bufsize)
eventNo
buffer
bufSize
ID number for the event, which will
appear on the viewgraph.
address of user supplied data.
NULL if none.
size of user supplied data, in bytes.

The buffer can contain user data which is passed up to
WindView on upload. This is displayed in a hex-dump
format.

Use this to programatically instrument events in your
code.
®
6-20
User Eventpoints
STATUS e (addr, eventNo, taskNameOrId,
evtRtn, arg)
Where:
addr
eventNo
taskNameOrId
evtRtn
arg
address to set eventpoint.
an event number for display.
the task ID of the task in which to
raise the eventpoint, 0 = all tasks.
function to call when event point is
hit. Event is logged if evtRtn’s
return value is zero.
an integer argument to pass to
evtRtn above.
®
6-21
WindView Example
Initialization:
Create message queue;
Spawn consumer task;
Spawn producer task;
Producer Task:
FOREVER
{
Allocate block;
Initialize data in
block;
Send pointer to
block across
message queue;
Delay one tick;
}
Consumer Task:
FOREVER
{
Wait for message
(pointer to block)
to arrive on queue;
Process data in
block;
Free block;
}
®
6-22
The Big Picture

Initialization and first few iterations of producer consumer program.
®
6-23
Zooming In

One cycle of the producer - consumer program.

Events are shown in the context in which they occur.
®
6-24
Searching for Events

Move cursor over event, and description
appears in status bar.

Double-click, and Show Event dialog
appears.
®
6-25
Too Many Events?

There are three means for filtering the data to reduce the
amount of information shown.
– The task pop-up menu can be used to hide any task. Right-click
on task name on left side of graph for a context menu. To act on
multiple tasks, select Attributes....
– Non-executing task states may be hidden by pressing the
appropriate button on the tool bar.
– Specific events and states may be filtered out using the “Filter
Events/States” dialog.

For help remembering WindView symbols, try:
– Move mouse over event, or double-click on event.
– Right-click on task state stipple, select Context State
– Right-click and select Legend to see event dictionary.
®
6-26
Task States and WindView

The Task State Summary display gives staticstics about
the intervals a task spends in different states. Right-click
on the task name on the left of the graph and select
Information to see this summary.

A running task has RUNNING in its state label. It may also
have either or both of LOCKED and INHERITED.
– Preemption locking and priority inheritance are covered in the
next chapter.

A task which is not running may be in any combination of
the PEND, DELAY, and SUSPEND states. If neither pended
nor delayed nor suspended, the task is READY.
®
6-27
Memory Events and Analysis Pack
®
6-28
Event Base API

Provides C++ and Tcl programmatic interfaces for
accessing and analyzing event log data in detail.

Provided as a dynamic link library.

Library implements objects representing:
– Event base as a whole.
– Task, ISR, or idle context.
– Individual event.
– Cursor for iterating through event base.

For more information:
– Appendix D of WindView User’s Guide
– Tornado Tools Workshop
®
6-29
Summary: WindView 2.0 vs. 1.0

Triggering on events now available.

More sophisticated buffer management.

The Target Server File System and alternative upload
paths.

User can hide irrelevant tasks.

Analysis packs extend analytical possibilities.

Summary data of task states are available on demand.

Event data are available via TCL or C++ API for further
analysis (the event-base API).
®
6-30