Hardware Troubleshooting

Installing the communications hardware and LayGO software is just the first step. Getting the hardware to connect to another system and transfer data is the next. Success in this step sometimes does not come on the first try. This section of the manual is designed to explain how to diagnose and resolve some common problems.

The primary tool for testing the hardware and software is the Tdrv test program. Tdrv is a GUI-based LayGO test program available for all platforms which support GUIs. Testing with Tdrv explains how the program works.

Testing the Hardware Installation

The first question which needs to be answered is:

Does the hardware you installed actually work?

Running Tdrv with a hardware loopback configuration tests the internal integrity of the hardware and the correctness of the installation. If Tdrv does not work in hardware loopback mode, nothing else will work either!

The LayGO distribution contains 2 configuration files necessary to run the hardware loopback test:

For instance, the Win32 version of Tdrv is WinTdrv. To run the test for board ID A under Windows, you would start WinTdrv with the following command line:

> wintdrv stacka.cfg x21loop.cfg

When WinTdrv starts, press Open, then Connect. When the Flags indicator turns green and WinTdrv enters data transfer state, press Send. Since x21loop.cfg puts the hardware into internal loopback mode, the frame should be immediately received and displayed in the Session Log window. Press Full-Duplex to toggle simultaneous sending and receiving on and off. (To exit WinTdrv, press Full-Duplex to stop data transfer, then Disconnect, Close and File/Exit.)

By default, Tdrv uses Verified Transmission Mode (VTX). When VTX is enabled, sender and receiver exchange a known set of frames so that the receiver can verify that the exact frame contents transmitted by the sender were received. The loopback test is successful only when there are no VTX errors reported.

Evaluating Tdrv Test Results

If the Tdrv test works in internal loopback mode, you can go on to Establishing a Physical Connection. Otherwise, what went wrong? Here are some common problems:

1. The Flags indicator never turns green. Tdrv does not enter data transfer state.
The Flags indicator turns green when the driver detects the SDLC flag pattern (hex 7E) on the receive data line. Since the board is in hardware loopback mode, this should happen immediately. The flags are automatically generated by the transmitter, so the problem is usually that the driver did not receive the interrupt generated by the hardware when the flags were detected. This means that the IRQ assigned to the board is not working properly. This can be caused by a hardware conflict or by an improperly configured BIOS.

Many ISA boards also require that the IO base address assigned be set on the board with a jumpers or dip-switches. Make sure the board is configured properly for the IO base address assigned.
2. Frames are never sent or are sent but never received.
This is an indication that the IRQ assigned to the board is not working properly. See the previous item for possible remedies.
3. Frames are received but with VTX errors.
This indicates that there is a hardware conflict of some kind, typically with the IO base address or the DP-RAM address.

Establishing a Physical Connection

Once the hardware has passed the loopback test, it is time to try connecting to the target device. This means connecting a cable from the communication board to the target device and, using an appropriate configuration, getting Tdrv to enter data transfer state. Only when Tdrv enters data transfer state can you move on to Transferring Data.

LayGO software has been used to connect to an astonishing variety of devices, some standard, some totally non-standard. However, there are always 2 basic issues to resolve:

The physical signals generally available are:

Signal Direction
DTR output
RTS output
DSR input
DCD input
CTS input
External Clock output
Transmit Clock input
Receive Clock input
Transmit Data output
Receive Data input

Where differential signaling is used (V.35, EIA-530), some or all of the signals are mapped to a pair of pins.

The LayGO hardware vendor's documentation should show the pinout of the board's physical connector and the supplied cable. The documentation for the target device should specify the details of it's physical interface. Some adjustment is often required to map the output signals of each side onto the corresponding input signals of the other. In many cases, this is merely a null-modem cable. The LayGO Hardware Guide shows some common null-modem cable layouts. In some cases, the mapping is not symmetrical. In addition, the correct cable layout may depend on which side is expected to generate the clock signal.

The LayGO X.21 bis configuration profile allows you to specify which physical signals to output, which to expect as input and whether the RTS/CTS pair, if available, should be used for hardware flow control. The LayGO Configuration Manual explains how to configure the signals.

Running Tdrv with the X.21 bis configuration profile you expect to use for your device can help diagnose connection problems. Tdrv will not enter data transfer state until all signals configured as input signals go high. If a signal stays red, Tdrv is not detecting a change in that signal. There are 2 possible explanations:

You can check whether the target device has actually raised the signal by probing the output pin with an oscilloscope or other device.

Transferring Data

Once Tdrv enters data transfer state, you can attempt to exchange data with the target device.

Running Tdrv with the X.21 bis configuration profile you expect to use for your device can help diagnose data transfer problems. Testing with Tdrv explains how to use test data frames. You can create some frames to which the target device will respond and send them using Tdrv. Tdrv will display any responses received from the device. For instance, if the target device uses HDLC LAPB, you can create SABM and DISC test data frames which will let you use Tdrv to test whether you can bring up and take down the LAPB link.

The most frequent problem encountered in transferring data is configuring the correct clock mode. Synchronous communication requires a reference clock signal which is used to encode and decode the data bits. Most communication boards can be configured to use a number of different clock modes. Typically, one side provides the clock signal for both sides to transmit data with. If neither side provides the clock, data cannot be transmitted by either side. If both sides provide the clock, the result is totally unpredictable. If the cable does not route the clock signals correctly, either side may be able to send data but not receive it or vice versa.

There is no general rule about the correct clock mode for a particular target device. The correct clock mode is the one the device expects! The LayGO Configuration Manual explains how to configure the clock mode.

Even when everything is configured correctly, special problems may prevent successful data transfer:

1. Board not jumpered correctly
Some boards may require special jumper or DIP switch settings in order to support a particular clock mode. See the LayGO Hardware Guide for details about your particular board.
2. Baud rate too high
Some boards may simply be unable to operate at the baud rate requested. For instance, the board may be unable to generate a useable clock signal at the requested frequency.
3. Baud rate generator frequency mismatch
In NRZI, FM0 and FM1 modes, the clock signal is encoded in the data signal, rather than being sent separately. Each side uses its own internal baud rate generator to sample the signal and decode both clock and data from it. If the internal baud rate generators of the board and traget device are not able to generate matching frequencies, they may not be able to decode what the other has encoded. In this situation, it may be necessary to change the crystal on the board or to use another board with a compatible crystal. If this appears to be the problem, contact technical support at Advanced Relay Corporation.