![[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).
semMCreate -- create a mutual exclusion semaphore
semMGiveForce -- give a mutual exclusion semaphore without restrictionsApplication code called the semMGiveForce( ) routine. This routine is intended as a debugging aid only; see the VxWorks 5.1 Reference Manual.
If tasks are pended on the mutex 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).
semTake -- take a semaphore System or application code called the semTake( ) routine.
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 the semaphore is full, it is made empty and the task continues executing (no effect on task state). If the semaphore is empty, the task pends on the semaphore, causing a context switch.
For counting semaphores, if the semaphore value is non-zero, it is decremented and the task continues executing (no effect on task state). If the semaphore value is zero, the task pends on the semaphore, causing a context switch.
For mutual exclusion semaphores, if the number of takes exceeds the number of gives, the task continues executing (no effect on task state). Otherwise, the task pends on the semaphore, causing a context switch.
kill -- send a signal to a taskThe task being signaled immediately suspends its current thread of execution and invokes the signal handler associated with this signal. (Note that the signal handler is invoked in the context of the task, even if the task is not in the ready state.) Depending on the actions of the signal handler, a context switch can occur.
pause -- pause the task until delivery of a signal
signal -- specify the handler associated with a signal
sigsuspend -- suspend the task until delivery of a signal
sigwrapper -- entry to signal handler
safePend -- pend or unpend a task attempting to delete a task that is safe from deletion
taskDelay -- delay a task In system code, the taskDelay( ) routine is used for synchronization purposes, especially in networking code and for shared memory objects.
taskDelete -- delete a taskIf the routine is successful, the specified task makes a transition from its previous state to the dead state. If the executing task deletes itself, a context switch occurs. However, if the specified task is safe from deletion, the calling task makes a transition to the pended state (see the safePend event) until the task is made unsafe by the appropriate number of taskUnsafe( ) routines (or until it releases the mutex semaphore that kept it safe).
Note that once a task is deleted, its task ID may be reused by tasks initialized after its deletion.
taskPrioritySet -- change the priority of a task
taskResume -- resume a taskThe suspended task makes a transition to the ready state. If it is the highest-priority ready task in the system, a context switch occurs.
Note that a task that was in a state other than executing or ready before it was suspended is returned to that state. For example, a delayed task that was suspended is now once again delayed, unless the timeout period has also expired.
taskSafe -- make a task safe from deletion
taskSpawn -- start a task
taskSuspend -- suspend a taskThe task makes a transition to the suspended state. If the calling task suspends itself, a context switch occurs.
Note that if a task was in a state other than executing or ready before it was suspended, it is still in that state. For example, a delayed task that is suspended is now delayed and suspended.
taskUnsafe -- make a task unsafe from deletionIf this taskUnsafe( ) routine released the last safe-from-deletion lock on the specified task, then any tasks in the pended state because they are waiting to delete this task are put into the ready state (see the safePend event). As soon as one of those tasks executes, the specified task is deleted; therefore, it makes a transition from its previous state to the dead state.
tick: timeout -- task timeout expiration
tick: timeslice -- announce a time sliceRound-robin scheduling was enabled with the kernelTimeSlice( ) routine, and a time slice has expired.
tick: undelay -- task delay expiration
tick: watchdog -- announce a watchdog timer expiration
unknown -- unknown event
defaultUser -- display user-specified event
|
|
|||||||||||||||||||
wdCancel -- cancel a watchdog timer
wdCreate -- create a watchdog timer
wdDelete -- delete a watchdog timer
wdStart -- start a watchdog timer
1: For information on starting event logging, see WindView User's Guide: Configuring Data Collection.
2: For a task, the context ID is the task ID. For an ISR context, the ID is the hex value of the interrupt level; for example, an ISR that runs at INT 3 has an ID of 0x3. For the idle loop context, the ID is 0xffffffff.
