![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
|
|||||||||||||||||||
You do not need much of this chapter if all you want to do is connect to a target that is already set up on your network. If this is the case, read 2.3 The Tornado Host Environment and then proceed to 2.6 Booting VxWorks.
The process of setting up a new target has the following steps (described in detail in the remainder of this chapter). Some of these steps are only required once, when you begin using Tornado for the first time; some are required when you install a new target; and only the last two are repeated frequently.
|
|
|||||||||||||||||||
Tornado host tools such as the shell and the 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.
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 must be configured with a back end that matches the target agent interface with which VxWorks has been configured and built. See Figure 2-1 for a detailed diagram of host-target communications.
All of the standard back ends included with Tornado connect to the target through the WDB 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 task mode, system mode, and dual mode.
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.
Nevertheless, there are situations where you may wish to use a non-network connection, such as a serial line without general-purpose IP, or a NetROM 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. Older versions of VxWorks network interface drivers such at netif do not support polled operations and so cannot be used as a connection for system-mode debugging.
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 perform 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 VxWorks Programmer's Guide: Configuration and Build. 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 VxWorks Programmer's Guide: Local File Systems. You can also boot from a host disk over a serial connection using the Target Server File System; see 2.6.7 Booting a Target Without a Network. Certain BSPs may provide other alternatives, such as flash memory. See the reference information for your BSP; Help>Manuals contents>BSP Reference in the Tornado Launcher.
Before anyone at your site can use Tornado, someone must set up the Tornado target server registry, a daemon that keeps track of all available targets by name. The registry daemon must always run; otherwise Tornado tools cannot locate targets.
Usage of the Tornado registry is initially determined during the software installation process, based on the installer's choice of options for the registry. See the Tornado Getting Started Guide for information about installation.
Only one registry is required on your network, and it can run on any networked host. It is recommended that a development site use a single registry for the entire network; this provides maximum flexibility, allowing any Tornado user at the site to connect to any target.
If there is already a registry running at your site, you do not need the remainder of this section; just make sure you know which host the registry is running on, and proceed to 2.3 The Tornado Host Environment.1
No privilege is required to start the registry, and it is not harmful to attempt to start a registry even if another is already running on the same host--the second daemon detects that it is not needed, and shuts itself down.
To start the registry daemon from a command line, execute wtxregd in the background. For example, on a Sun-4 running Solaris 2.x:
% installDir/host/sun4-solaris2/bin/wtxregd -V >/tmp/wtxregd.log &
This example uses the -V (verbose) option to collect diagnostic output in a logging file in /tmp. We recommend this practice, so that status information from the registry is available for troubleshooting.
To ensure that the registry remains available after a system restart, run wtxregd from a system startup file. For example, on Sun hosts, a suitable file is /etc/rc2. Insert lines like the following in the appropriate system startup file for your registry host. The example below uses conditionals to avoid halting system startup if wtxregd is not available due to some unusual circumstance such as a disk failure.
#
# Start up Tornado registry daemon
#
if [ -f /usr/wind/host/host-os/bin/wtxregd ]; then
WIND_HOST_TYPE=host-os
export WIND_HOST_TYPE
WIND_BASE=/usr/wind
export WIND_BASE
/usr/wind/host/host-os/bin/wtxregd -V -d /var/tmp >/tmp/wtxregd.log &
echo -n 'Tornado Registry started'
fi
The Tornado tools locate the registry daemon through the environment variable WIND_REGISTRY; each Tornado user must set this variable to the name of whatever host on the network runs wtxregd.
In some cases, you may wish to segregate some collections of targets; to do this, run a separate registry daemon for each separate set of targets. Developers can then use the WIND_REGISTRY environment variable to select a registry host.
One of the more exotic applications of Tornado is to set this environment variable to a remote site; this allows the Tornado environment to execute remotely. Using a remote registry can bridge two separate buildings, or even enable concurrent development on both sides of the globe! As a support mechanism, it allows customer support engineers to wire themselves into a remote environment. This application often requires setting WIND_REGISTRY to a numeric Internet address, since the registry host may not be mapped by domain name. For example (using the C shell):
% setenv WIND_REGISTRY 127.0.0.1
If WIND_REGISTRY is not set at all, the Tornado tools look for the registry daemon on the local host.
You can query the registry daemon for information on currently-registered targets using the auxiliary program wtxreg. See the online Tornado API Reference for more information about both wtxreg and wtxregd.
2.3.1 Environment Variables for Tornado Components discusses all Tornado environment variables.
|
|
|||||||||||||||||||
You can also set X Window System resources to allow the Tornado tools to benefit from color or grayscale displays; see 2.3.4 X Resource Settings.
Specify the location of Tornado facilities by defining the following environment variables on your development host:
If you use the C shell, add lines like the following to your .cshrc to reflect your Tornado development environment. After you modify the file, be sure to source it and execute the rehash command.
The following example is for a Sun-4 host running Solaris 2.x, in a network whose Tornado registry is on host mars:
setenv WIND_BASE /usr/wind
setenv WIND_HOST_TYPE sun4-solaris2
setenv WIND_REGISTRY mars
setenv PATH ${WIND_BASE}/host/sun4-solaris2/bin:${PATH}
setenv LD_LIBRARY_PATH ${WIND_BASE}/host/sun4-solaris2/lib:${LD_LIBRARY_PATH}
If you are using the Bourne shell (or a compatible shell, such as the Korn shell or Bash), add lines like the following to your .profile to reflect your Tornado development environment. Be sure to source the file (using the "." command) after you modify the file.
The following example is for an Solaris host in a network whose Tornado registry is on host venus:
WIND_BASE=/usr/wind; export WIND_BASE WIND_HOST_TYPE=sun4-solaris2; export WIND_HOST_TYPE WIND_REGISTRY=venus; export WIND_REGISTRY PATH=$WIND_BASE/host/sun4-solaris2/bin:$PATH; export PATH SHLIB_PATH=$WIND_BASE/host/sun4-solaris2/bin:$SHLIB_PATH; export SHLIB_PATH
If your development host runs Solaris 2, you must also modify the value of LD_LIBRARY_PATH to include the shared libraries in /usr/dt/lib, /usr/openwin/lib, and installDir/host/sun4-solaris2/lib.
If you use the C shell, include a line like the following in your .cshrc:
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/usr/dt/lib:/usr/openwin/lib
If you use the Bourne shell (or a compatible shell), include lines like the following in your .profile:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/dt/lib:/usr/openwin/lib export LD_LIBRARY_PATH
Certain other environment variables, though they are not required for Tornado, can make the tools fit in better with your site or with your habits. The following environment variables are in this category:
Tornado has resource definitions to cover the range of X Window System displays. For better use of color or grayscale displays with Tornado, set customization resources in your X-resource initialization file (usually a file named .Xdefaults or .Xresources in your home directory). There are three possible values for these resources:
The following example (for a color display) shows customization settings specified explicitly for each of the Tornado tools:
Browser*customization: -color CrossWind*customization: -color Dialog*customization: -color Launch*customization: -color Tornado*customization: -color
Alternately, you can set customization globally for all tools that use this property. The following example does this for a grayscale display:
*customization: -grayscale
|
|||||||||||||||||||
For more information about X resources in Tornado, see E. X Resources.
|
|
|||||||||||||||||||
VxWorks is a flexible system that has been ported to many different hardware platforms.The default VxWorks run-time development configuration is shown in Figure 2-2. The pre-built VxWorks images shipped with your BSP include all the necessary components to run on this hardware configuration.
The configuration in Figure 2-2 consists of the following:
IP networking over Ethernet is the most desirable way to connect a development target to your host, because of the high bandwidth it provides. This section describes setting up simple IP connections to a target over Ethernet. To read about other communication strategies, see 2.5 Host-Target Communication Configuration.
Before VxWorks can boot an executable image obtained from the host, the network software on the host must be correctly configured. There are three main tasks in configuring the host network software for VxWorks:
|
|
|||||||||||||||||||
Most UNIX systems automatically initialize the network subsystem and activate network processes in the startup files /etc/rc2 and /etc/rc.boot. This typically includes configuring the network interface with the ifconfig command and starting various network daemons. Consult your UNIX system manuals if your UNIX startup procedure does not initialize the network.
The UNIX host system maintains a file of the names and network addresses of systems accessible from the local system. This database is kept in the ASCII file /etc/hosts, which contains a line for each remote system. Each line consists of an Internet address and the name(s) of the system at that address. This file must have entries for your host UNIX system and the VxWorks target system.
For example, suppose your host system is called mars and has Internet address 90.0.0.1, and you want to name your VxWorks target phobos and assign it address 90.0.0.50. The file /etc/hosts must then contain the following lines:
90.0.0.1 mars 90.0.0.50 phobos
The UNIX system restricts network access through remote login, remote command execution, and remote file access. This is done for a single user with the .rhosts file in that user's home directory, or globally with the /etc/hosts.equiv file.
The .rhosts file contains a list of system names that have access to your login. Thus, to allow a VxWorks system named phobos to log in with your user name and access files with your permissions, create a .rhosts file in your home directory containing the line:
phobos
The /etc/hosts.equiv file provides a less selective mechanism. Systems listed in this file are allowed login access to any user defined on the local system (except the super-user root). Thus, adding the VxWorks system name to /etc/hosts.equiv allows the VxWorks system to log in with any user name on the system.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
In every case, you will need to create your own boot medium. Your board will require one of the following media:
For specific information on a BSP's booting method, see Help>Manuals contents>BSP Reference in the Tornado Launcher. Instructions for making a floppy disk for booting a Pentium target are in the VxWorks for Pentium Architecture Supplement.
You may also wish to replace a boot ROM, even if it is available, with a ROM emulator. This is particularly desirable if your target has no Ethernet capability, because the ROM emulator can be used to provide connectivity at near-Ethernet speeds. Tornado includes support for one such device, NetROM.2 For information about how to use NetROM on your target, refer to 2.5.4 The NetROM ROM-Emulator Connection. Contact the nearest Wind River office (see copyright page) for information about support for other ROM emulators.
For cases where boot ROMs are used to boot VxWorks, install the appropriate set of boot ROMs on your target board(s). When installing boot ROMs, be careful to:
See 4.8 Configuring and Building a VxWorks Boot Program for instructions on creating a new boot program with parameters customized for your site.
Many CPU and Ethernet controller boards still have configuration options that are selected by hardware jumpers, although this is less common than in the past. These jumpers must be installed correctly before VxWorks can boot successfully. You can determine the correct jumper configuration for your target CPU from the information provided in the target-information reference for your BSP; see Help>Manuals contents>BSP Reference in the Tornado Launcher.
For bare-board targets, use the power supply recommended by the board manufacturer (often a PC power supply).
If you are using a VME chassis, install the CPU board in the first slot of the backplane. See Figure 2-3.
Many systems also require the P2 bus. Some boards require power on the P2 connector, and some configurations require the extended address and data lines of the B row of the P2 bus.
Alternatively, a separate system controller board can be installed in the first slot and the CPU and Ethernet boards can be plugged into the next two slots.
All supported VxWorks targets include at least one on-board serial port. This serial port must be connected to an ASCII terminal (or equivalent device) for the default configuration. After the initial configuration of the boot parameters and getting started with VxWorks, you may wish to configure VxWorks to boot automatically without a terminal. Refer to the CPU board hardware documentation for proper connection of the RS-232 signals.
For the Ethernet connection, a transceiver cable must be connected from the Ethernet controller to an Ethernet transceiver.
Connecting the target server to the target in a configuration other than the default requires a little work on both the host and target. The next few subsections describe the details for network connections, END connections, serial line connections, the NetROM Emulator, and the transparent mode driver.
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.
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 wdbpipe back end (see Target-Server Configuration Options).
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.
The default VxWorks system image is configured for a networked target. See 4.7 Configuring the Target-Host Communication Interface for information about configuring VxWorks for various target agent communications interfaces.
See Configuration for an END Driver Connection for information about configuring the VxWorks target agent for an END connection.
Figure 2-4 illustrates a minimal cross-development configuration: the target is a bare board, connected to the host development system by a single serial line. For a configuration of this sort, use a combination of a boot mechanism that does not require a network and an alternative Tornado communications back end.
Tornado can operate over a raw serial connection between the host and target systems, and can operate on standalone systems that have no network connection to other hosts.
When you connect the host and target exclusively over serial lines, you must:
For more information, see 4.7 Configuring the Target-Host Communication Interface.
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.
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.
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 Configuration for Serial Connection).
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 4.8 Configuring and Building a VxWorks Boot Program). The simplest way to boot over a serial connection is by using the Target Server File System. See 2.6.7 Booting a Target Without a Network.
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.
Before trying to attach the target server for the first time, test the serial connection to the target. To help verify the connection, the target agent sends the following message over the serial line when it boots (with WDB_COMM_SERIAL):
WDB READY
To test the connection, attach a terminal emulator3 to the target-agent serial port, then reset the target. 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.
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 installDir/target/src/config/usrWdb.c.
#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 */
In both calls to wdbSioTest( ), change the last argument from 0 to 0300.
With this configuration, attach any terminal emulator on the host to the tty 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.
|
|
|||||||||||||||||||
After successfully testing the serial connection, you can connect the target server to the agent by following these steps:
% tgtsvr -V targetname -B wdbserial -bps 38400 &
You can also use the Tornado GUI to configure and start a target server (see 3.5 Managing Target Servers).
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 office (listed on the back cover) for information about support for other ROM emulators. Figure 2-5 illustrates this connection method.
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.
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.
For information about booting a target without a network, see 2.6.7 Booting a Target Without a Network.
To configure the target agent for a NetROM communication connection, reconfigure and rebuild VxWorks with a NetROM interface for the target agent. Several configuration macros are used to describe a board's memory interface to its ROM banks. You may need to override some of them for your board. See Configuration for NetROM Connection.
Before a target server on your host can connect to the target agent over NetROM, some hardware and software configuration is necessary. The following steps outline this process.
When it powers up, the NetROM knows its own Ethernet address, but does not know its internet (IP) address.
There are two ways of establishing an IP address for the NetROM:
Since the RARP and BOOTP requests are broadcast, any host connected to the same subnet can reply. Configure only one host to reply to NetROM requests.
After the NetROM obtains its IP address, it loads a startup file. The pathname for this file depends on which protocol establishes the IP address:
The startup file contains NetROM commands describing the emulated ROM, the object format, path and file names to download, and so on. The following example NetROM startup file configures the Ethernet device, adds routing information, records the object-file name to download and the path to it, and establishes ROM characteristics.
Example 2-1: Sample NetROM Startup File
begin
ifconfig le0 147.11.46.164 netmask 255.255.255.0 broadcast 147.11.46.0
setenv filetype srecord
setenv loadpath /tftpboot
setenv loadfile vxWorks_rom.hex
setenv romtype 27c020
setenv romcount 1
setenv wordsize 8
setenv debugpath readaddr
set udpsrcmode on
tgtreset
end
|
|
|||||||||||||||||||
For more information regarding NetROM boot requirements, refer to NetROM documentation. Consult your system administrator to configure your host to reply to RARP or BOOTP requests (or see host-system documentation for bootpd or rarpd).
|
|
|||||||||||||||||||
Once the required NetROM address and boot information is configured on a host, the NetROM can be powered up. To verify that the NetROM has obtained its IP address and loaded and executed the startup file, you can connect to a NetROM command line with a telnet session.
The following example shows the expected response from a NetROM at IP address 147.11.46.164:
% telnet 147.11.46.164 Trying 147.11.46.164 Connected to 147.11.46.164 Escape character is `^]' NETROM TELNET NetROM>
At the NetROM prompt, you can display the current configuration by entering the command printenv to verify that the startup file executed properly.
One method is to type the newimage command at the NetROM prompt. This command uses the TFTP protocol to download the image specified by the loadfile environment variable from the path specified by the loadpath environment variable (which is /tftpboot/vxWorks_rom.hex if you use the startup script in Example 2-1). After the NetROM configuration is stable, you can include this command in the startup file to download the image automatically. Wait to be certain the image is completely downloaded before you power up your target. This method takes about 30 seconds to transfer the image.
A faster method is to use two host utilities from AMC: rompack packs a ROM image into a compact file (with the default name outfile.bin); download ships the packed file to the NetROM. This method takes only about five seconds to transfer a new image to the target. This UNIX shell script shown in uses these utilities to send an image to the NetROM whose IP address is recorded in the script variable ip:
#! /bin/sh
if [ $# != 1 ]; then
echo "Usage: $0 <filename>"
exit 1
fi
file=$1 ip=t46-154
if [ -r "$file" ]; then
echo "Downloading $file to the NetROM at $ip."
rompack -c 1 -r 27c020 -x $file 0 0
download outfile.bin $ip
else
echo "$0: \"$file\" not found"
exit 1
fi
echo Done. exit 0
The rompack option flags specify how to pack the image within the emulator pods. The -c 1 option specifies a ROM count of one, which means that the image goes in a single ROM socket. The -r 27c020 option specifies the type of ROM. The two trailing numbers are the base and offset from the start of ROM space. Both are typically zero.
Start the target server as in the following example, using the -B option to specify the NetROM back end.
% tgtsvr -V 147.11.46.164 -B netrom &
In this example, 147.11.46.164 is the IP address of the NetROM. (You can also use the Tornado GUI to configure and start a target server; see Tornado Getting Started Guide.)
If the connection fails, try typing the following command at the NetROM prompt:
NetROM> set debugecho on
With this setting, all packets sent to and from the NetROM are copied to the console. You may need to hook up a connector to the NetROM serial console to see the debugecho output, even if your current console with NetROM is attached through Telnet (later versions of NetROM software may not have this problem). If you see packets sent from the host, but no reply from the target, you must modify the target NetROM configuration parameters described in section Configuration for Network Connection.
|
|
NOTE:
With a NetROM connection, you must inform the NetROM when you reboot the target. You can do this as follows at the NetROM prompt:
NetROM> tgtreset |
||||||||||||||||||
It is possible that the NetROM is not correctly configured for downloading code to the target. Make sure you can download and run a simple piece of code (for example, to blink an LED -- this code should be something simpler than a complete VxWorks image).
If you can download code and execute it, the next possibility is that the board initialization code is failing. In this case, it never reaches the point of trying to use the NetROM for communication. The code in target/src/config/usrWdb.c makes a call to wdbNetromPktDevInit( ). If the startup code does not get to this point, the problem probably lies in the BSP. Contact the vendor that supplied the BSP for further troubleshooting tips.
|
|
|||||||||||||||||||
When you rerun VxWorks with this modification, the wdbNetromPktDevInit( ) routine attempts to print a message to NetROM debug port. The initialization code halts until you connect to the debug port (1235), which you can do by typing:
% telnet NetROM_IPaddress 1235
If the debug port successfully connects, the following message is displayed in the telnet window:
WDB NetROM communication ready
If you do not see this message, the NetROM dual-port RAM has not been configured correctly. Turn off the processor cache; if that does not solve the problem, contact AMC for further trouble shooting tips:
If everything has worked up to this point, reset wdbNetromTest back to zero and end your telnet session.
Type the following at the NetROM prompt:
NetROM> set debugecho on
This causes data to be echoed to the NetROM console when packets are transmitted between the host and target. If you have a VxWorks console available on your target, edit wdbNetromPktDrv.c by changing the following line:
int wdbNetromDebug = 0;
int wdbNetromDebug = 1;
This causes messages to be echoed to the VxWorks console when packets are transmitted between the host and target.
|
|
|||||||||||||||||||
At this point, you have debugging output on three levels: the target server is recording all transactions between it and the NetROM box; the NetROM box is printing all packets it sees to its console; and the WDB agent is printing all packets it sees to the VxWorks console. If this process does not provide enough debug information to resolve your problems, contact Wind River technical support for more troubleshooting assistance.
The TM driver provides the same connection capability as an Ethernet or serial cable would. However, the TM driver works through the Wind River visionICE II/visionPROBE II hardware debug tools. Physically, the connection is implemented over the BDM/JTAG/EJTAG emulation connection provided by the tools. This can be advantageous if the target being used does not have an Ethernet or serial port on it, or if the ports are required for something else. It can also be useful when the target ports are available, but the software that controls them is not yet working.
The Wind River TM driver supports both system and task level debugging. The TM driver also supports the /vio (virtual I/O) sub-channel of the WDB protocol.
The TMD is added to the current build by selecting the VxWorks tab in the project dialog window. Expand the VxWorks entry associated with your project, and from the list that appears, select development tool components>select WDB connection>WDB visionTMD connection.
For the TMD to be added to the current build, the WDB visionTMD connection entry must be made the active WDB connection. By default, when this project was built, the WDB END driver connection was included in the project. That entry now appears bolded because it is the active connection.
In order for the project to build correctly, only one WDB connection can be active. To include the WDB visionTMD connection, right-click on Select WDB connection and select Configure `select WDB connection' on the pop-up menu. The properties dialog wind appears.
Click on the Components tab, scroll down the list, and click on the WDB visionTMD connection check box. The WDB END driver connection will automatically be deselected. Click the Apply button to select the TMD component. If the Include Component(s) dialog contains the correct information, click Ok to confirm it and close the dialog box. The WDB visionTMD connection is now the active connection.
The debugger being used must be configured correctly to download the vxWorks image created in the previous steps to the target. The debugger will also be used to start the image running once it has been downloaded. Once the image is running on the target, the TM Driver will also be available since the WDB agent that is included in the vxWorks image uses the TM Driver as the connection mechanism.
Instructions for configuring the debugger and downloading and executing the vxWorks image on the target are provided for two of Wind Rivers debuggers in the Transparent Mode Driver User's Guide.
|
|
|||||||||||||||||||
Information on configuring visionICE II for network operation is available in the visionICE II User's Manual. In addition, the UDP Console Port must be set to 17185.
Once the VxWorks image is running on the target, the host will be able to communicate with the running WDB agent. To do this, a target server must be configured and activated. Follow the following steps:
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
To launch a correctly configured target server using the command line, enter:
% tgtsvr.exe -n 127.0.0.1 -V -B wdbrpc -R C:/Tornado/2.2 -RW -c myCoreFile
For more information about using either the GUI or the command line to configure target servers, see 2.7 Connecting a Tornado Target Server.
Once you have correctly configured your host software and target hardware, establish a terminal connection from your host to the target, using the serial port that connects the two systems.4 For example, the following command starts a tip session for the second serial port at 9600 bps:
% tip /dev/ttyb -9600
See your BSP documentation for information about the bps rate (Help>Manuals contents>BSP Reference in the Tornado Launcher, or see the file installDir/docs/BSP_Reference.html).
You are now ready to turn on the target system power and boot VxWorks.
When you boot VxWorks with the default boot program (from ROM, diskette, or other medium), you must use the VxWorks command line to provide the boot program with information that allows it to find the VxWorks image on the host and load it onto the target. The default boot program is designed for a networked target, and needs to have the correct host and target network addresses, the full path and name of the file to be booted, the user name, and so on.5
When you power on the target hardware (and each time you reset it), the target system executes the boot program from ROM; during the boot process, the target uses its serial port to communicate with your terminal or workstation. The boot program first displays a banner page, and then starts a seven-second countdown, visible on the screen as shown in Figure 2-6. Unless you press any key on the keyboard within that seven-second period, the boot loader will attempt to proceed with a default configuration, and will not be able to boot the target with VxWorks.
To interrupt the boot process and provide the correct boot parameters, first power on (or reset) the target; then stop the boot sequence by pressing any key during the seven-second countdown. The boot program displays the VxWorks boot prompt:
[VxWorks Boot]:
To display the current boot parameters, type p at the boot prompt, as follows:
[VxWorks Boot]: p
A display similar to the following appears; the meaning of each of these parameters is described in the next section. This example corresponds to the configuration shown in Figure 2-7. (The p command does not actually display blank fields, although this illustration shows them for completeness.)
boot device : ln processor number : 0 host name : mars file name : installDir/target/config/bspname/vxWorks inet on ethernet (e) : 90.0.0.50:ffffff00 inet on backplane (b) : host inet (h) : 90.0.0.1 gateway inet (g) : user (u) : fred ftp password (pw)(blank=use rsh) : flags (f) : 0x0 target name (tn) : phobos startup script (s) : other (o) :
To change the boot parameters, type c at the boot prompt, as follows:
[VxWorks Boot]: c
In response, the boot program prompts you for each parameter. If a particular field has the correct value already, press RETURN. To clear a field, enter a period ( . ), then RETURN. If you want to quit before completing all parameters, type CTRL+D.
Network information must be entered to match your particular system configuration. The Internet addresses must match those in /etc/hosts on your UNIX host, as described in Establishing the VxWorks System Name and Address.
If your target has nonvolatile RAM (NVRAM), boot parameters are retained there even if power is turned off. For each subsequent power-on or system reset, the boot program uses these stored parameters for the automatic boot configuration.
The VxWorks boot program provides a limited set of commands. To see a list of available commands, type either h or ? at the boot prompt, followed by RETURN:
[VxWorks Boot]: ?
Table 2-4 lists and describes each of the VxWorks boot commands and their arguments.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
Each of the boot parameters is described below, with reference to the example in 2.6.2 Entering New Boot Parameters. The letters in parentheses after some parameters indicate how to specify the parameters in the command-line boot procedure described in 2.6.6 Alternate Booting Procedures.
