Hardware Interface

To enable very efficient and device-independent testing of modules, possibly from multiple controller manufacturers, a standardized hardware interface is defined that can be used by UTs. The hardware interface is a simple two-wire UART that has a single line for

transmitting bits from the UT to the DUT, and another line for transmitting bits from the DUT to the UT. It is expected that module manufacturers and end-product manufacturers will expose two pins or pads that can be connected to the UT on a production line to allow for calibration and verification of an individual product’s ability to transmit and receive.

6.3.1. UART

UARTs are typically very flexible in how they can be configured. To reduce the problem of an incompatible interface, the Direct Test Mode UART only has one configurable

parameter: baud rate.

The baud rate for the DUT can be one of the following values: 1200, 2400, 9600, 14400, 19200, 38400, 57600, or 115200. The typical rate is 38400 because this is a good

compromise between efficient command and event transfer and implementation cost.

The rest of the UART parameters are very standard. Each byte is 8 bits in length, sent with no parity, and one stop bit. There is no flow control, either software or hardware.

Obviously, it is impossible to do hardware flow control because there are no hardware flow control wires. Software flow control is also not required because a command or event is only a maximum of 2 bytes in length and only one command can be sent at a time. The final

design parameter is a common ground. It is assumed that there is a common ground between the two devices.

To send a command or event, 2 bytes of data must be sent a maximum of 5 milliseconds apart. Once a command is sent, an event must be returned within 50 milliseconds. This

ensures that the DUT starts and stops tests in a timely manner, and therefore, the accuracy of any counting is easily validated.

6.3.2. Commands and Events

Four commands can be sent from the UT to the DUT:

• Reset

• Transmitter Test

• Receiver Test

• Test End

Two events can be sent from the DUT to the UT:

• Test Status

• Packet Reporting

The reset command does exactly as it says. It stops the controller at whatever point it is

located; if the controller was transmitting or receiving test packets, it must stop. It also places the controller into a known good state. It immediately returns a test status event to confirm that everything is back to the quiescent state. Only 2 bits within the reset command are used;

all other bits are ignored.

The transmitter test command starts the transmitter test. This includes the three

parameters: frequency, length, and packet type, as shown in Figure 6–2. Once this command is received, the DUT sends a test status event and starts transmitting packets using the

parameters. If for some reason the device cannot transmit packets, the DUT still returns the test status event but sets the status bit to denote an error. If the transmitter test command failed to start, the UT would need to reset the DUT to place it into a known good state.

Figure 6–2. The Direct Test Mode command bit structure

The receiver test command starts the receiver test. This includes the frequency parameter;

all other bits in this packet are ignored. Once this command is received, the test status event is returned and the DUT starts receiving packets on the desired frequency. Again, if the

device cannot receive any packets, the test status event is returned with the status bit showing an error.

After a successful transmitter or receiver test, the test end command can be sent by the

UT to stop the test. When this command is received by the DUT, it immediately stops what it was doing and returns the packet reporting event. If the receiver test was being run, this packet-reporting event includes the packet count for the successfully received packets (see Figure 6–3). If the transmitter test was being run, this field in the event is set to zero because no packets are received in the transmitter test. After the packet-reporting event is received, the UT can start another test by using another test command.

Figure 6–3. Direct Test Mode events reporting bit structure

The test status event only defines a single bit. If this bit is zero, the test command was successful. If this bit is one, the test command failed for some reason. There are two possible reasons a test command fails:

• The controller is in a state that confuses it, and a reset is probably the most suitable next step for the UT.

• The controller doesn’t support the test, probably because it doesn’t have either a transmitter or receiver. (Although it possible to test the receiver of a transmitter-only device.)

It is not possible to determine from this command set if the DUT supports a given test; a UT can only try each test and determine the status.

The packet-reporting event is used to report that the test completed. It includes a single 15-bit packet count of the number of successfully received packets. This packet count will always be zero for transmitter tests, but can be any value from 0 to 32,767 for receiver tests.

The DUT doesn’t worry about overflow of the packet counter; if the packet counter

overflows, a test that might have taken a very long time can determine that only one packet was received, even though 32,769 packets were actually received. UTs should therefore only run tests for a duration that would not cause overflow of the packet counter.