c-xfer2.html

vxworks相关论文

</p callout>



<dl class="margin">

<dd><p class="Body"><a name="86242"> </a>The data of interest is typically the data collected just before the failure. For this reason, the ring buffer is set to wrap around if it overflows, overwriting earlier data. Any existing data in an individual buffer is lost as soon as the first byte in that buffer is overwritten. To minimize the amount of data lost in this way, WindView automatically configures a large number of small buffers in the ring buffer for post-mortem mode. The number of buffers in the ring depends on how much memory you assign to post-mortem storage in your buffer configuration. </p>
<dd><p class="Body"><a name="86527"> </a>WindView reserves the first four 32-bit words in the specified range for its own use. It creates a memory partition in the remainder, reserving a buffer in which to store task names and using the remainder for the ring buffer. The task name information is sent to the host with the logged data. This means that task names are retained in addition to task IDs at all times. </p>
<dd><p class="Body"><a name="85046"> </a>When you select <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Post-Mortem</font></b> mode on the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Control Properties</font></b> dialog box, the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Buffer Configuration</font></b> portion of the dialog box changes. (See <a href="c-xfer2.html#86249">Figure&nbsp;8-1</a>.) Use this dialog box to specify the lower and upper addresses of the range where you want your post-mortem buffer stored. For example, suppose you have 0x4000000 bytes of system memory starting at address 0x0000000. If your target does not reinitialize memory on a warm reboot, you could enter 0x3f80000 in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">sysMemTop</font></b> box and 0x3ffffff in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">sysPhysMemTop </font></b>box to configure a 512K buffer. Or suppose you have 0x4000000 bytes of system memory plus an equal amount of shared memory assigned to the addresses 0x4000000-0x7ffffff. If you wished to use all the shared memory for your post-mortem buffer, you would enter 0x4000000 in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">sysMemTop</font></b> box and 0x7ffffff in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">sysPhysMemTop </font></b>box.&nbsp;&nbsp;<div class="frame">
<h4 class="EntityTitle"><a name="86249"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 8-1:&nbsp;&nbsp;Post-Mortem Buffer Configuration </font></a></h4>

<dl class="margin">

<div class="CellBody"><a name="86262"> </a><img class="figure" border="0" src="images/c-xfera4.gif">
</div>



</dl>

</div>
 </p>
<dd><p class="Body"><a name="86295"> </a>If your target does reinitialize the entire system partition during a warm reboot, and you have no other source of memory for your post-mortem buffer, you must reconfigure VxWorks to reserve a portion of the system memory so that it is not overwritten on reboot. This procedure is described in <a href="c-xfer2.html#85527"><i class="title">Configuring VxWorks to Reserve System Memory for Post-Mortem Mode</i></a>. </p>
</dl>

<dd>
<p class="table" callout>
<table border="0" cellpadding="0" cellspacing="0">
<tr valign="top">
<td valign="top" width="40">
<br>
<img border="0" alt="*" src="icons/warning.gif">
</td>

<td>
<hr><div class="CalloutCell"><a name="90259"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">WARNING:  </font></b></a>If you reconfigure your system to reserve a system memory partition for your post-mortem buffer, you must rebuild your VxWorks image, rebuild your boot ROM, reboot your target, and reset the WindView configuration by clicking <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Reset</font></b> in the<b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans"> Collection Configuration</font></b> dialog box to pick up these changes. The lower and upper address of the preserved area now appear in the<b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans"> Control Properties</font></b> dialog box. Note that they are preset to correspond to the values returned by <b class="routine"><i class="routine">sysMemTop</i></b><b>(&nbsp;)</b> and <b class="routine"><i class="routine">sysPhysMemTop</i></b><b>(&nbsp;)</b>. Care should be taken to ensure that these values are valid for the specific target board you are using, as some BSPs return a preset, minimum value for onboard memory. </div>
</td>


</tr>
<tr valign="top">
<td></td>

<td><hr></td>


</tr>

<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p callout>



</dl>
<dl class="margin">

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="85527">Configuring VxWorks to Reserve System Memory for Post-Mortem Mode </a></i></h5>
</font></dl>

<dl class="margin">
<dd>
<p class="table" callout>
<table border="0" cellpadding="0" cellspacing="0">
<tr valign="top">
<td valign="top" width="40">
<br>
<img border="0" alt="*" src="icons/note.gif">
</td>

<td>
<hr><div class="CalloutCell"><a name="90234"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE:  </font></b></a>The information in this section applies only to WRS-style BSPs. Although third-party BSP developers are encouraged to follow WRS conventions, it is not a requirement. Thus, memory size configuration mechanisms described here may differ for non-WRS BSPs. Consult the BSP vendor for more information. If you wish to adapt your BSP to follow WRS conventions, see <i class="title">Wind Technical Note #41: Reserving User Memory</i>.</div>
</td>


</tr>
<tr valign="top">
<td></td>

<td><hr></td>


</tr>

<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p callout>



<dl class="margin">

<dd><p class="Body"><a name="84633"> </a>All Wind River Systems BSPs include a macro, <b class="symbol_UC">USER_RESERVED_MEM</b>, configurable if <b class="symbol_UC">INCLUDE_MEMORY_CONFIG</b> is selected. Set this macro to the size in bytes of the area you wish to reserve for the post-mortem buffer. </p>
<dd><p class="Body"><a name="84637"> </a>The memory reserved with this macro is immediately after the top of memory used by VxWorks; thus, you can use the return value of <b class="routine"><i class="routine">sysMemTop</i></b><b>(&nbsp;)</b> to point to the reserved block of memory. All Wind River Systems BSPs include a routine called <b class="routine"><i class="routine">sysPhysMemTop</i></b><b>(&nbsp;)</b> in <b class="file">sysLib.c</b> whose result is the top of all local memory, as opposed to the top of memory used by VxWorks. Thus to reserve 512K of memory for your post-mortem log, change <b class="symbol_UC">USER_RESERVED_MEM</b> to (0x80000) on the <b class="symbol_UC">INCLUDE_MEMORY_CONFIG</b> <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Params</font></b> tab or make the following change in <b class="file">config.h</b>:</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="84643">#define USER_RESERVED_MEM&nbsp;&nbsp;&nbsp;(0x80000)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* number of reserved bytes */</a></b></pre>
</dl>

</dl>

</dl>
<dl class="margin">

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="84814">Rebuilding the Boot ROM After Reserving System Memory</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="84816"> </a>Note that the VxWorks boot ROM must be rebuilt when you use this method of configuring for post-mortem mode. To make sure that the boot process does not clear the memory you reserve for the event buffer, you must rebuild the boot ROM (as well as the VxWorks system image) with the changes to memory allocation described in the previous section. </p>
<dd><p class="Body"><a name="84818"> </a>For instructions on rebuilding VxWorks and on rebuilding boot ROMs, see the <i class="title">Tornado User's Guide</i>: <i class="title">Projects</i>. After you rebuild the boot ROM and system image, verify that the target still runs as expected, that the reserved area of local memory is not used by the system image, and that the reserved area of local memory is not cleared during a reboot.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="85634">Configuring the Upload Task</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="85637"> </a>The upload task, <b class="task">tWVUpload</b>, uploads the contents of the event buffer to the host. </p>
<dd><p class="Body"><a name="85668"> </a>In deferred analysis and post-mortem modes, the task is spawned when upload is requested, empties the ring buffer, and exits. In continuous mode, the task is spawned when data collection is requested but before it starts, and it runs until logging is stopped, waiting for more data to be written to the buffers.</p>
<dd><p class="Body"><a name="86060"> </a>The default settings for <b class="task">tWVUpload</b> are usually appropriate, but if necessary, you can configure the priority and stack size of <b class="task">tWVUpload</b> by calling <b class="routine"><i class="routine">wvUploadTaskConfig</i></b><b>(&nbsp;)</b>. </p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="87851">wvUploadTaskConfig 
    ( 
    int stackSize,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* the new stack size for tWVUpload */ 
    int priority&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* the new priority for tWVUpload */ 
    )</a></b></pre>
</dl>

<dd><p class="Body"><a name="87845"> </a>The default value of <i class="textVariable">stackSize</i> is 5000 bytes; the default of <i class="textVariable">priority</i> is 150.</p>
<dd><p class="Body"><a name="86833"> </a>If any higher-priority tasks execute often enough to prevent <b class="task">tWVUpload</b> from executing, the event buffer cannot be uploaded. In the case of continuous mode, the logging mechanism turns itself off. In the case of deferred and post-mortem modes, the task will time out before upload occurs. If you see these symptoms, try increasing the priority level of <b class="task">tWVUpload</b>.</p>
</dl>

</dl>


<a name="foot"><hr></a>


<p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="c-xfer.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-xfer.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-xfer1.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-xfer3.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p>

</body>

</html>
<!---
by WRS Documentation (), Wind River Systems, Inc.
    conversion tool:  Quadralay WebWorks Publisher 4.0.11
    template:         CSS Template, Jan 1998 - Jefro --->