7.0 Software User Information
31.25 MHz. Some of this energy is aliased in the 10 Mb/s
domain and for specific cable lengths, between 35meters
to 41meters or equivalent attenuation, is falsely detected
as FLP pulses. At these specific cable lengths, the Auto-
Negotiation receive state machine will misconstrue enough
FLP pulses such that it fits the FLP template, thereby
notifying the arbitration state machine of the receipt of FLP
pulses.
7.1 100 Mb/s Full Duplex Log-On
Problem:
Certain Software drivers that were developed for the
DP83840 do not account for the longer auto-negotiation
time that is required for the DP83840A to complete Auto-
Negotiation. This is discussed in the IEEE specification
802.3U from draft D2 to D5. The Auto-Negotiate time has
increased from 1 second to approximately 3 seconds
between the two devices.
At the same time the misconstrued FLP’s are being
detected, the arbitration state machine is moving through
the parallel detection path. This causes the arbitration state
machine to think that it is receiving both FLP pulses and
100 Mb/s scrambled idles, thereby, causing a parallel
detection fault (MLF bit 4 set high in the Auto-Negotiation
expansion register (06h)), and hanging the Auto-
Negotiation process.
Description:
The problem can be seen when the server or the client
physical layer device is the DP83840A. When the client is
attempting to log on to the server the user will see CRC
errors occurring until the client times out and disconnects.
The driver software that was written for the DP83840
needs to be modified to account for the additional time per
the specification 802.3(D5.3) that is required for the
DP83840A to complete Auto-Negotiation.
Symptoms:
This problem only occurs when a system using the
DP83840A is in Auto-Negotiation mode and tries to
establish link with a system that is sending out 100 Mb/s
scrambled idles and the cable length is approximately
35meters to 41 meters or equivalent attenuation. When the
problem occurs the following will be observed:
Symptoms:
A Novell server and a Novell DOS client that are connected
via a crossover cable will not log on to 100 Mb/s Full
Duplex with the DP83840A in the client or the server.
Solution/Workaround:
A.) Pin 38 (Link LED) will go low indicating 100 Mb/s
activity.
The solution is to modify the driver software to
accommodate the longer Auto-Negotiation time that is
required. The basic script should be the following:
B.) The Multiple Link Fault bit (bit 4) of the Auto-
Negotiation Expansion Register (06h) is HIGH, indicating
the DP83840A thinks FLP’s were being received.
A.) Wait for auto-negotiation to complete (Three seconds)
B.) Verify whether the auto-negotiation is completed by
reading BSMR bit<5>.
C.) The Link Status bit (bit 2) of the Basic Mode Status
Register (01h) is LOW, indicating link not established.
C.) If BMSR<5> is set read the BMSR to update the link
status BMSR<2>.
D.) The Auto-Negotiation Complete bit (bit 3) in the Basic
Mode Status Register (01h) is LOW, indicating Auto-
Negotiation not complete.
D.) If the BMSR<2> is set, read the PAR (19h) register.
PAR bits<7:6> reflect the Duplex_STAT and Speed_10
status.
Solution/Workaround:
For existing products using the DP83840A the following
can be done to work around the problem:
7.2 Auto-Negotiation to Link Sending 100 Mb/s
Scrambled Idles.
A.) Manually configure the system using the DP83840A
into 100 Mb/s mode through software. Many installation
programs already support this capability.
Problem:
B.) Modify software driver to detect fault condition. A
proposed software driver work around for this problem
follows:
The DP83840A when Auto-Negotiating with a 100 Mb/s
link partner that is sending out 100 Mb/s scrambled idles
can, for specific cable lengths, approximately 35 to 41
meters or equivalent attenuation, misinterpret the 100 Mb/s
scrambled idles as FLP’s (Fast Link Pulses), thereby
causing a false MLF (Multiple Link Fault) condition which
hangs the Auto-Negotiation process (No link established).
The workaround is based upon the concept that a
DP83840A that is failing to complete negotiation is
attempting to negotiate with a non-Auto-Negotiation-
capable 100 Mb/s link partner. In that case, the software
driver can force the local node/port directly into 100 Mb/s
Half-Duplex mode to complete negotiation. Half-Duplex
100 Mb/s mode is what the Auto-Negotiation logic would
select had the fault not occurred. The total time that Auto-
Negotiation will take to complete is under 3 seconds.
Therefore, the proposed software driver should implement
the following:
This problem only occurs with the above scenario and
does not affect other methods of linking such as Auto-
Negotiating to a 10 Mb/s link partner, Auto-Negotiating to a
Auto-Negotiation link partner, forcing the DP83840A into
100 Mb/s mode and linking to a 100 Mb/s link partner, and
forcing the DP83840A into 10 Mb/s mode and linking to a
10 Mb/s link partner.
Reset the 840A the DP83840A by writing 8000h to BMCR
register, or re-start Auto-Negotiation by writing 1200h to
BMCR register. Wait 3 seconds then read bit 5 (Auto-
Negotiation Complete bit) and bit 2 (Link_Status bit) in the
Description:
When Scrambled 100 Mb/s idles are transmitted, the
energy is dispersed across the spectrum from 1MHz to
Version A
National Semiconductor
67
TI [ TEXAS INSTRUMENTS ]
