
12.0 Loopback Diagnostics
(Continued)
PATH
TCR
RCR
TSR
RSR
ISR
NIC External
04
00
43(1)
02
02
Note 1:
CDH is set, CRS is not set since it is generated by the external
encoder/decoder.
PATH
TCR
RCR
TSR
RSR
ISR
NIC External
06
00
03(1)
02
02(2)
Note 1:
CDH and CRS should not be set. The TSR however, could also
contain 01H,03H,07H and a variety of other values depending on whether
collisions were encountered or the packet was deferred.
Note 2.
Will contain 08H if packet is not transmittable.
Note 3:
During external loopback the NIC is now exposed to network traffic,
it is therefore possible for the contents of both the Receive portion of the
FIFO and the RSR to be corrupted by any other packet on the network. Thus
in a live network the contents of the FIFO and RSR should not be depended
on. The NIC will still abide by the standard CSMA/CD protocol in external
loopback mode. (i.e. The network will not be disturbed by the loopback
packet).
Note 4:
All values are hex.
CRC AND ADDRESS RECOGNITION
The next three tests exercise the address recognition logic
and CRC. These tests should be performed using internal
loopback only so that the NIC is isolated from interference
from the network. These tests also require the capability to
generate CRC in software.
The address recognition logic cannot be directly tested. The
CRC and FAE bits in the RSR are only set if the address of
the packet matches the address filters. If errors are expect-
ed to be set and they are not set, the packet has been
rejected on the basis of an address mismatch. The following
sequence of packets will test the address recognition logic.
The DCR should be set to 40H, the TCR should be set to
03H with a software generated CRC.
Packet Contents
Results
Test
Address
CRC
RSR
Test A
Test B
Test C
Matching
Matching
Non-Matching
Good
Bad
Bad
01(1)
02(2)
01
Note 1:
Status will read 21H if multicast address used.
Note 2:
Status will read 22H if multicast address used.
Note 3:
In test A, the RSR is set up. In test B the address is found to match
since the CRC is flagged as bad. Test C proves that the address recognition
logic can distinguish a bad address and does not notify the RSR of the bad
CRC. The receiving CRC is proven to work in test A and test B.
Note 4:
All values are hex.
NETWORK MANAGEMENT FUNCTIONS
Network management capabilities are required for mainte-
nance and planning of a local area network. The NIC sup-
ports the minimum requirement for network management in
hardware, the remaining requirements can be met with soft-
ware counts. There are three events that software alone
can not track during reception of packets: CRC errors,
Frame Alignment errors, and missed packets.
Since errored packets can be rejected, the status associat-
ed with these packets is lost unless the CPU can access the
Receive Status Register before the next packet arrives. In
situations where another packet arrives very quickly, the
CPU may have no opportunity to do this. The NIC counts
the number of packets with CRC errors and Frame Align-
ment errors. 8-bit counters have been selected to reduce
overhead. The counters will generate interrupts whenever
their MSBs are set so that a software routine can accumu-
late the network statistics and reset the counters before
overflow occurs. The counters are sticky so that when they
reach a count of 192 (C0H) counting is halted. An additional
counter is provided to count the number of packets NIC
misses due to buffer overflow or being offline.
The structure of the counters is shown below:
TL/F/8582–63
Additional information required for network management is
available in the Receive and Transmit Status Registers.
Transmit status is available after each transmission for infor-
mation regarding events during transmission.
Typically, the following statistics might be gathered in soft-
ware:
Traffic:
Frames Sent OK
Frames Received OK
Multicast Frames Received
Packets Lost Due to Lack of Resources
Retries/Packet
Errors:
CRC Errors
Alignment Errors
Excessive Collisions
Packet with Length Errors
Heartbeat Failure
32