📄 c-start4.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Setup and Startup </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-start.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-start3.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-start5.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="90094">2.4 Host-Target Communication Configuration</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90095"> </a>Tornado host tools such as the shell and debugger communicate with the target system through a target server. A target server can be configured with a variety of back ends, which provide for various modes of communication with the target agent. On the target side, VxWorks can be configured and built with a variety of target agent communication interfaces. </p><dd><p class="Body"><a name="93707"> </a>Your choice of target server back end and target agent communication interface is based on the mode of communication that you establish between the host and target (network, serial, and so on). In any case, the target server <i class="emphasis">must</i> be configured with a back end that matches the target agent interface with which VxWorks has been configured and built. See <a href="c-start4.html#93843">Figure 2-5</a> for a detailed diagram of host-target communications.</p><dd><p class="Body"><a name="94014"> </a>The default configurations for both the VxWorks target agent and Tornado target servers are for a network connection. If you are using a network connection, you can proceed with booting your target (<a href="c-start5.html#92648"><i class="title">2.5 Booting VxWorks</i></a>).</p></dl></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/warning.gif"></td><td><hr><div class="CalloutCell"><a name="93715"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">WARNING: </font></b></a>If you are using a connection other than network (the default), you must rebuild VxWorks with the appropriate target agent communication interface, and configure a target server with the corresponding back end, before you can use Tornado tools with your target. See <a href="c-builder6.html#99096"><i class="title">4.6 Configuring the Target-Host Communication Interface</i></a> and <a href="c-tools2.html#84049"><i class="title">5.2 Configuring and Starting a Target Server</i></a>. </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="93833"> </a>All of the standard target server back ends included with Tornado connect to the target through the target agent. Thus, in order to understand the features of each back end, you must understand the modes in which the target agent can execute. These modes are called <i class="term">task mode</i>, <i class="term">system mode</i>, and <i class="term">dual mode</i>.<div class="frame"><h4 class="EntityTitle"><a name="93843"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-5: Tornado Host-Target Communication</font></a></h4><dl class="margin"><div class="CellBody"><a name="93964"> </a><img class="figure" border="0" src="images/c-startb7.gif"></div></dl></div></p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="90216"> </a>In <i class="term">task mode</i>, the agent runs as a VxWorks task. Debugging is performed on a per-task basis: you can isolate the task or tasks of interest without affecting the rest of the target system. </li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="90218"> </a>In <i class="term">system mode</i>, the agent runs externally from VxWorks, almost like a ROM monitor. This allows you to debug an application as if it and VxWorks were a single thread of execution. In this mode, when the target run-time encounters a breakpoint, VxWorks and the application are stopped and interrupts are locked. One of the biggest advantages of this mode is that you can single-step through ISRs; on the other hand, it is more difficult to manipulate individual tasks. Another drawback is that this mode is more intrusive: it adds significant interrupt latency to the system, because the agent runs with interrupts locked when it takes control (for example, after a breakpoint). </li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="90220"> </a>In <i class="term">dual mode</i>, two agents are configured into the run-time simultaneously: a task-mode agent, and a system-mode agent. Only one of these agents is active at a time; switching between the two can be controlled from either the Tornado debugger (CrossWind; see <a href="c-debugger6.html#85341"><i class="title">8.6 System-Mode Debugging</i></a>) or the shell (<a href="c-shell2.html#91110"><i class="title">6.2.6 Using the Shell for System Mode Debugging</i></a>). In order to support a system-mode agent, the target communication path must work in polled mode (because the external agent needs to communicate to the host even when the system is suspended). Thus, the choice of communication path can affect what debugging modes are available.</li></ul></p></dl><dl class="margin"><dd><p class="Body"><a name="90227"> </a>The most common VxWorks communication path--both for server-agent communications during development, and for applications--is IP networking over Ethernet. That connection method provides a very high bandwidth, as well as all the advantages of a network connection. </p><dd><p class="Body"><a name="90229"> </a>Nevertheless, there are situations where you may wish to use a non-network connection, such as a serial line or a ROM-emulator connection. For example, if you have a memory-constrained application that does not require networking, you may wish to remove the VxWorks network code from the target system during development. Also, if you wish to perform system-mode debugging, you need a communication path that can work in polled mode. VxWorks network interface drivers that do not support polled operations (older versions) cannot be used as a connection for system-mode debugging.</p><dd><p class="Body"><a name="90230"> </a>Note that the target-server back end connection is not always the same as the connection used to load the VxWorks image into target memory. For example, you can boot VxWorks over Ethernet, but use a serial line connection to exploit a polled-mode serial driver for system-mode debugging. You can also use a non-default method of getting the run-time system itself into your target board. For example, you might burn your VxWorks run-time system directly into target ROM, as described in <i class="title">VxWorks Programmer's Guide: Configuration and Build</i>. Alternatively, you can use a ROM emulator such as NetROM to quickly download new VxWorks images to the target's ROM sockets. Another possibility is to boot from a disk locally attached to the target; see the <i class="title">VxWorks Programmer's Guide: Local File Systems</i>. You can also boot from a host disk over a serial connection using the Target Server File System; see <a href="c-start5.html#94118"><i class="title">2.5.7 Booting a Target Without a Network</i></a>.Certain BSPs may provide other alternatives, such as flash memory; see the reference information for your BSP.</p><dd><p class="Body"><a name="90234"> </a>Connecting the target server to the target requires a little work on both the host and target. The next few subsections describe the details for the standard target-server back end connections. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="90237">2.4.1 Network Connections</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90239"> </a>A network connection is the easiest to set up and use, because most VxWorks targets already use the network (for example, to boot); thus, no additional target set-up is required. Furthermore, a network interface is typically a board's fastest physical communication channel. </p><dd><p class="Body"><a name="90741"> </a>When VxWorks is configured and built with a network interface for the target agent (the default configuration), the target server can connect to the target agent using the default <i class="acronym_lc">wdbrpc</i> back end (see <a href="c-tools2.html#84049"><i class="title">5.2 Configuring and Starting a Target Server</i></a>).</p><dd><p class="Body"><a name="90822"> </a>The target agent can receive requests over any device for which a VxWorks network interface driver is installed. The typical case is to use the device from which the target was booted; however, any device can be used by specifying its IP address to the target server.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="91616">Configuring the Target Agent For Network Connection</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90844"> </a>The default VxWorks system image is configured for a networked target. See <a href="c-builder6.html#99096"><i class="title">4.6 Configuring the Target-Host Communication Interface</i></a> for information about configuring VxWorks for various target agent communications interfaces.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="91626">2.4.2 END Connections</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="91627"> </a>An END (Enhanced Network Driver) connection supports dual mode agent execution. This connection can only be used if the BSP uses an END driver (which has a polled interface). With an END connection, the agent uses an END driver directly, rather than going through the UDP/IP protocol stack.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="91638">Configuring the Target Agent For END Connection</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="91639"> </a>See <a href="c-builder6.html#99146"><i class="title">Configuration for an END Driver Connection</i></a> for information about configuring the VxWorks target agent for an END connection.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="90248">2.4.3 Serial-Line Connections</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90251"> </a>A raw serial connection has some advantages over an IP connection. The raw serial connection allows you to scale down the VxWorks system (even during development) for memory-constrained applications that do not require networking: you can remove the VxWorks network code from the target system. </p><dd><p class="Body"><a name="90252"> </a>When working over a serial link, use the fastest possible line speed. The Tornado tools--especially the browser and the debugger--make it easy to set up system snapshots that are periodically refreshed. Refreshing such snapshots requires continuing traffic between host and target. On a serial connection, the line speed can be a bottleneck in this situation. If your Tornado tools seem unresponsive over a serial connection, try turning off periodic updates in the browser, or else closing any debugger displays you can spare.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="90254">Configuring the Target Agent For Serial Connection</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90262"> </a>To configure the target agent for a raw serial communication connection, reconfigure and rebuild VxWorks with a serial communication interface for the target agent (see <a href="c-builder6.html#99220"><i class="title">Configuration for Serial Connection</i></a>).</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="94168">Configuring the Boot Program for Serial Connection</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="94171"> </a>When you connect the host and target exclusively over serial lines, you must configure and build a boot program for the serial connection because the default boot configuration uses an FTP download from the host (see <a href="c-buildera7.html#103278"><i class="title">4.7 Configuring and Building a VxWorks Boot Program</i></a>). The simplest way to boot over a serial connection is by using the Target Server File System. See <a href="c-start5.html#94118"><i class="title">2.5.7 Booting a Target Without a Network</i></a>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="90281">Testing the Connection</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90283"> </a>Be sure to use the right kind of cable to connect your host and target. Use a simple Tx/Tx/GND serial cable because the host serial port is configured not to use handshaking. Many targets require a null-modem cable; consult the target-board documentation. Configure your host-system serial port for a full-duplex (no local echo), 8-bit connection with one stop bit and no parity bit. The line speed must match whatever is configured into your target agent.</p><dd><p class="Body"><a name="90284"> </a>Before trying to attach the target server for the first time, test that the serial connection to the target is good. To help verify the connection, the target agent sends the following message over the serial line when it boots (with <b class="symbol_UC">WDB_COMM_SERIAL</b>):</p><dl class="margin"><dd><pre class="Code2"><b><a name="90285">WDB READY</a></b></pre></dl><dd><p class="Body"><a name="90292"> </a>To test the connection, attach a terminal emulator to the target-agent serial port, then reset the target (see <a href="c-start3.html#84767"><i class="title">Connecting a Serial Cable for Terminal Emulator</i></a>). If the WDB READY message does not appear, or if it is garbled, check the configuration of the serial port you are using on your host. </p><dd><p class="Body"><a name="91654"> </a>As a further debugging aid, you can also configure the serial-mode target agent to echo all characters it receives over the serial line. This is not the default configuration, because as a side effect it stops the boot process until a target server is attached. If you need this configuration in order to set up your host serial port, edit <b class="file">target\src\config\usrWdb.c</b>. </p><dd><p class="Body"><a name="90294"> </a>Look for the following lines:</p><dl class="margin"><dd><pre class="Code2"><b><a name="90295">#ifdef INCLUDE_WDB_TTY_TEST /* test in polled mode if the kernel hasn't started */ if (taskIdCurrent == 0) wdbSioTest (pSioChan, SIO_MODE_POLL, 0); else wdbSioTest (pSioChan, SIO_MODE_INT, 0); #endif /* INCLUDE_WDB_TTY_TEST */</a></b></pre></dl><dd><p class="Body"><a name="90296"> </a>In both calls to <b class="routine"><i class="routine">wdbSioTest</i></b><b>( )</b>, change the last argument from 0 to 0300. </p><dd><p class="Body"><a name="90297"> </a>With this configuration, attach any terminal emulator on the host to the COM port connected to the target to verify the serial connection. When the serial-line settings are correct, whatever you type to the target is echoed as you type it. </p></dl></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/warning.gif"></td><td><hr><div class="CalloutCell"><a name="92457"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">WARNING: </font></b></a>This configuration change also prevents the target from completing its boot process until a target server attaches to it. Thus, it is best to change the <b class="routine"><i class="routine">wdbSioTest</i></b><b>( )</b> calls back to the default as soon as you verify that the serial line is set up correctly. </div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="90310">Starting the Target Server</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90312"> </a>After successfully testing the serial connection, you can connect the target server to the agent by following these steps:</p></dl><dl class="margin"><p><ol class="List"><li value="1."><a name="90313"> </a>Close the serial port that you opened for testing (if you do not close the port, then it will be busy when the target server tries to use it).</li></ol></p><p><ol class="List"><li value="2."><a name="90314"> </a>Start the target server with the serial back end to connect to the agent. Use the <b class="command">tgtsvr</b> <b class="command">-B</b> option to specify the back end, specify the communications port with <b class="command">-d</b>, and also specify the line speed to match the speed configured into your target:</li></ol></p><dl class="margin"><dd><pre class="Code2"><b><a name="90316"></b><tt class="output">C:\> </tt><b>tgtsvr -V <i class="textVariable">targetname</i> -d com1 -B wdbserial -bps 38400 </a></b></pre></dl><dl class="margin"><dd><div class="Indent"><a name="90318"> </a>You can also use the Tornado GUI to configure and start a target server (see <a href="c-tools2.html#84049"><i class="title">5.2 Configuring and Starting a Target Server</i></a>). </div><br></dl></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="90342">2.4.4 The NetROM ROM-Emulator Connection</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="90344"> </a>The agent can be configured to communicate with the target server using the target board's ROM socket. Tornado supports this configuration for NetROM, a ROM emulator produced by Applied Microsystems Corporation. Contact your nearest Wind River Systems office (listed on the back cover) for information about support for other ROM emulators. <a href="c-start4.html#90351">Figure 2-6</a> illustrates this connection method.<div class="frame"><h4 class="EntityTitle"><a name="90351"><font face="Helvetica, sans-serif" size="-1" class="sans">Figure 2-6: Connecting a Target through NetROM</font></a></h4><dl class="margin"><div class="Anchor"><a name="90436"> </a><img class="figure" border="0" src="images/c-start20.gif"></div></dl></div> </p><dd><p class="Body"><a name="90437"> </a>The NetROM acts as a liaison between the host and target. It communicates with the host over Ethernet, and with the target through ROM emulation pods that are plugged into the target board's ROM sockets. The NetROM allows you to download new ROM images to the target quickly. In addition, a 2 KB segment of the NetROM's emulation pod is dual-port RAM, which can be used as a communication path. The target agent uses the NetROM's read-only protocol to transfer data up to the host. It works correctly even on boards that do not support write access to the ROM banks.</p><dd><p class="Body"><a name="90438"> </a>This communication path has many benefits: it provides a connection which does not intrude on any of your board's I/O ports, it supports both task-mode and system-mode debugging, it is faster than a serial-line connection, and it provides an effective way to download new VxWorks images to the target.</p></dl></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">⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -