![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
This chapter provides a "dictionary" of the events collected by WindView. It lists each event by object type (message queue, semaphore, task, and so on), providing the following information for each:
Figure 2-1 shows the paradigm that Wind River Systems used to create the default WindView icons.
This section provides tips for using the event dictionary.
Suppose you see the icon
while viewing an event log in WindView.
You can click on the icon to see the name of the event in the Tornado status line (at the bottom of the Tornado window; see the WindView User's Guide: Data Display). As an alternative, you can locate the icon in the Legend window under WindView Help in the main Help menu. In either case, you can see that this is the taskResume event icon. Using 2.3 Event Dictionary, you can look up the information on what can cause a taskResume event, what effect on the task state it may have, and what information is collected for a taskResume event, as shown in Figure 2-2.
Most of the elements that are called out on the sample page are self-explanatory, with the possible exception of the table of information collected.
The table of information collected describes what information is logged for a particular event, and for which event-logging level that information is logged (indicated by X's in the appropriate columns):
In the sample event dictionary page above, you can see that the context (the task, ISR, or idle loop in which the event occurred), eventName, and taskId event parameters are logged when event logging is started at TST level.1
At this level, timeStamp is not actually logged. Instead, it is calculated based on the next exit from the kernel; for more information, see the WindView User's Guide: Configuring Data Collection.
These same event parameters are logged when event logging is started at AIL level, but in addition, the priority event parameter is logged, and the timeStamp is logged rather than calculated.
For example, if event logging is at TST level, when you inspect the taskResume icon with the Show Event dialog box, a display like Figure 2-2 appears (note that although the priority label is present, its value is unknown, indicated by "?").
This provides the following information:
[1] At calculated time 0.0336625 seconds,
[2] within the context of tWdbTask (context ID 0x3fe9742 ), a taskResume event occurred.
[3] The priority of the resumed task is not known for this -logging level.
[4] The task being resumed has an ID of 0x33b6a7c, displayed here both as taskId in the Parameters area, and in the Object field (because this task is the object affected by the event).
However, if event logging is at AIL level, and task tWdbTask is instrumented, the Time field shows an exact timestamp, and the priority property displays the task priority for the affected task.
|
|||||||||||||||||||
|
|
|||||||||||||||||||
exception -- program error A program error generated an exception (such as divide by zero, or a bus or address error) to which only the default exception handler has been attached.
intEnt -- entry to ISRA hardware interrupt occurred for which there is an associated ISR. Interrupts not connected to the associated ISR by the intConnect( ) routine are not instrumented.
If the interrupt occurs in the context of an executing task, the task is displayed as making a transition to the ready state when the ISR starts executing.
VxWorks routines called from an ISR may be deferred to the interrupted context, if the interrupted context was doing kernel work at the time it was interrupted.
|
|
|||||||||||||||||||
intExit -- exit from ISRWhen this ISR finishes executing, control returns to the interrupted context. If the interrupted context was a task, then the highest-priority ready task makes a transition to the executing state.
VxWorks routines called from an ISR may be deferred to the interrupted context, if the interrupted context was doing kernel work at the time it was interrupted.
|
|
|||||||||||||||||||
memPartAddToPool-- add memory to a memory pool
memPartAlignedAlloc -- allocate memory System or application code called the malloc( ), calloc( ), valloc( ), memAlign( ), memPartAlloc( ), or memPartAlignedAlloc( ) routine.
memPartCreate -- create a memory partition
memPartFree -- free memory
memPartRealloc -- reallocate memory
msgQCreate -- create a message queue
msgQDelete -- delete a message queueSystem or application code called the msgQDelete( ) routine.
System code uses message queues for the following reasons (for information on TFTP, the exception task, and the logging task, see the VxWorks Programmer's Guide):
msgQReceive -- receive a message from a message queue System or application code called the msgQReceive( ) routine.
System code uses message queues for the following reasons (for information on TFTP, the exception task, the logging task, and pipes, see the VxWorks Programmer's Guide):
msgQSend -- send a message to a message queue System code, application code, or an ISR called the msgQSend( ) routine.
System code uses message queues for the following reasons (for information on TFTP, the exception task, the logging task, and pipes, see the VxWorks Programmer's Guide):
If tasks are pended on the message queue, the first task that called msgQReceive( ) or the highest-priority task (depending on the message queue creation option) makes a transition to the ready state. If it is the highest-priority task in the system, a context switch occurs.
If the message queue is full, and the sending task has specified a timeout, then it makes a transition to the pended state and a context switch occurs. (ISRs must specify NO_WAIT as the timeout value.)
semBCreate -- create a binary semaphore
semCCreate -- create a counting semaphore
semDelete -- delete a semaphoreSystem or application code called the semDelete( ) routine. (System code issues this routine from the TFTP library only.)
The following system tasks create and use mutex semaphores (for information on these facilities, see the VxWorks Programmer's Guide):
In addition, system code creates and uses these mutex semaphores:
semFlush -- flush a semaphoreSystem code, application code, or an ISR called the semFlush( ) routine. (System code only issues this routine from the TFTP library.)
|
|||||||||||||||||||
semGive -- give a semaphore System code, application code, or an ISR called the semGive( ) routine. (An ISR cannot give a mutual exclusion semaphore.)
WindView system code creates and uses a binary semaphore to manage the target event buffer.
The following system tasks create and use mutex semaphores (for information on these facilities, see the VxWorks Programmer's Guide):
In addition, system code creates and uses these mutex semaphores:
For binary semaphores, if tasks are pended on the semaphore, the first task that called semTake( ) or the highest-priority task (depending on the semaphore create option) makes a transition to the ready state. If it is the highest-priority task in the system, a context switch occurs. If there are no tasks pending on the semaphore, the semaphore becomes full (no effect on task state).
For counting semaphores, if tasks are pended on the semaphore, the first task that called semTake( ) or the highest-priority task (depending on the semaphore create option) makes a transition to the ready state. If it is the highest-priority task in the system, a context switch occurs. If there are no tasks pending on the semaphore, the count of the semaphore is incremented (no effect on task state).
For mutual exclusion semaphores, if the number of gives equals the number of takes, the first task that called semTake( ) or the highest-priority task (depending on the semaphore create option) makes a transition to the ready state. If it is the highest-priority task in the system, a context switch occurs. Otherwise, the semaphore count is decremented (no effect on task state).
