If you encountered problems booting or exercising VxWorks, there are many possible causes. This section discusses the most common sources of error and how to narrow the possibilities. Please read 2.10.1 Things to Check before contacting the Wind River customer support group. Often, you can locate the problem just by re-checking the installation steps, your hardware configuration, and so forth.

Most often, a problem with running VxWorks can be traced to configuration errors in hardware or software. Consult the following checklist to locate a problem.

Start with a minimal configuration of a single target CPU board and possibly an Ethernet board.

For targets on a VMEbus backplane, most configurations require that the P2 B row is bussed and that there is power supplied to both the P1 and P2 connectors.

The only exception to this is if the backplane is jumpered to propagate the BUS GRANT and INT ACK daisy chains.

In most cases, the documentation accompanying your hardware describes its cabling requirements. One common problem: make sure your serial cable is a null-modem cable, if that is what your target requires.

If the CPU board seems completely dead when applying power (some have front panel LEDs) or shows some error condition (for example, red lights), the boot ROMs may be inserted incorrectly. You can also validate the checksum printed on the boot ROM labels to check for defects in the ROM itself.

Some system controller boards do not reset the backplane on power-on; you must reset it manually.

Refer to the target-information reference for your BSP to determine the correct jumper settings for your target and Ethernet boards.

For example, connect a known working system to the transceiver and check whether the network functions.

An Internet address consists of a network number and a host number. There are several different classes of Internet addresses that assign different parts of the 32-bit Internet address to these two parts, but in all cases the network number is given in the most significant bits and the host number is given in the least significant bits. The simple configuration described in this chapter assumes that the host and target are on the same network--they have the same network number. (See VxWorks Network Programmer's Guide: TCP/IP Under VxWorks for a discussion of setting up gateways if the host and target are not on the same network.) If the target Internet address is not on the same network as the host, the VxWorks boot program displays the following message:

NetROM> tgtreset 

0x33 corresponds to errno 51 (decimal) ENETUNREACH. (This is one of the POSIX error codes, defined for VxWorks in /target/h/errno.h.)

If the target Internet address is not in /etc/hosts (or the NIS equivalent), then the host does not know about your target. The VxWorks boot program receives an error message from the host:

host name for your address unknown 
Error loading file: status = 0x320001.

0x32 is the VxWorks module number for hostLib 50 (decimal). The digit "1" corresponds to S_hostLib_UNKNOWN_HOST. See the errnoLib reference manual entry for a discussion of VxWorks error status values.

The target name must be listed in either of the files userHomeDir/.rhosts or /etc/hosts.equiv. The target user name can be any user on the host, but do not use the user name root --special rules often apply to it, and circumventing them creates security problems on your host.

Make sure that the user name you are using on the target has access to the host files. To verify that the user name has permission to read the vxWorks file, try logging in on the host with the target user name and accessing the file (for instance, with the UNIX size command). This is essentially what the target does when it boots.

If you have trouble with access permissions, you might try using FTP (File Transfer Protocol) instead of relying on RSH (remote shell). Normally, if no password is specified in the boot parameters, the VxWorks object module is loaded using the RSH service. However, if a password is specified, FTP is used. Sometimes FTP is easier because you specify the password explicitly, instead of relying on the configuration files on the host. Also, some non-UNIX systems do not support RSH, in which case you must use FTP. Another possibility is to try booting using BOOTP and TFTP; see VxWorks Network Programmer's Guide: File Access Applications.

Unless you specify an FTP password in your boot parameters, or include NFS-client support in your VxWorks image, the default VxWorks access to host-system files is based on capturing file contents through the rcmd( ) interface to the UNIX host. For user accounts whose default shell is the C shell, this makes it imperative to avoid issuing any output from .cshrc. If any of the commands in .cshrc generates output, that output can interfere with downloading host files accurately through rcmd( ). This problem most often shows up while downloading the VxWorks boot image.

To check whether the .cshrc file is causing booting problems, rename it temporarily and try booting VxWorks again. If this proves to be the source of the problem, you may want to set up your .cshrc file to conditionally execute any commands that generate standard output. For example, commands used to set up interactive C shells could be grouped at the end of the .cshrc and preceded with the following:

# skip remaining setup if a non-interactive shell: 
if (${?USER} == 0 || ${?prompt} == 0 || ${?TERM} == 0) exit

If noclobber is set in your .cshrc, be sure to un-set or move it to the section that is executed (as shown above) only if there is an interactive shell.

In tracking down configuration problems, the following UNIX tools can be helpful:

This command indicates whether packets are reaching a specified destination. For example, the following indicates this host is successful sending packets to phobos:

% ping phobos 
phobos is alive

This command reports the configuration of a specified network interface (for example, ie0 or le0 on a Sun system). It should report that the interface is configured for the appropriate Internet address and that the interface is up. The following example shows that interface le0, whose address is 137.10.1.3, is up and running:

% ifconfig -a 
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> 
inet 137.10.1.3 netmask ffffff00 broadcast 137.10.1.0 
lo0: flags=49<UP,LOOPBACK,RUNNING> 
inet 127.0.0.1 netmask ff000000 

This command displays the "address resolution protocol" tables that map Internet addresses to Ethernet addresses. Your target machine is listed if at least one packet was transferred from your target to your host. The following example shows saturn's Internet address (92.0.9.54) and Ethernet address (8:10:5:3:a5:c).

% arp -a 
saturn (92.0.9.54) at 8:10:5:3:a5:c

This command can be used on many UNIX systems to watch all traffic on a network. You must have root access to execute etherfind. For example, to monitor traffic between mars and phobos from a third machine, enter the following:

# etherfind between mars phobos 
Using interface le0 
                                 icmp type 
lnth  proto  source   destination  src port  dst port 
  60  tcp      mars        phobos      1022     login 
  60  tcp    phobos          mars     login      1022 
  60  tcp      mars        phobos      1022     login 
   ... 

etherfind displays the packet length, the protocol (for example, TCP, UDP), the source and destination machine names, and the source and destination ports.

This command displays network status reports. The -r option displays the network routing tables. This is useful when gateways are used to access the target. In the following example, this node sends packets for 91.0.10.34 through gateway vx210:

% netstat -r 
Routing tables 
Destination    Gateway   Flags   Refcnt  Use    Interface 
91.0.10.34     vx210     UG      0       0      le0 

If you use a WDB Serial connection to the target, make sure you have connected the serial cable to a port on the target system that matches your target-agent configuration. The agent uses serial channel 1 by default, which is different from the channel used by VxWorks as a default console (channel 0). Your board's ports may be numbered starting at one; in that situation, VxWorks channel one corresponds to the port labeled "serial 2."

The target server requires a host-resident image of the VxWorks run-time system. By default, it obtains a path for this image from the target agent (as recorded in the target boot parameters). In some cases (for example, if the target boots from a local device), this default is not useful. In that situation, use the Core file field in the Create Target Server form (3.5 Managing Target Servers) or the equivalent -c option to tgtsvr (C. Tornado Tools Reference) to specify the path to a host-resident copy of the VxWorks image.

If you have questions or problems with Tornado or with VxWorks after completing the above troubleshooting section, or if you think you have found an error in the software, contact the Wind River Systems technical support organization. Your comments and suggestions are welcome as well.

The Tornado launcher has facilities to help you submit trouble reports; you can use them even if you were unable to hook up a target. See 9. Customer Service.